[Gluster-Maintainers] Community Transparency [Was: Responsibilities and expectations of our maintainers]
srangana at redhat.com
Wed Jun 24 14:01:15 UTC 2015
On 06/24/2015 01:06 AM, Venky Shankar wrote:
> On 06/24/2015 10:09 AM, Krishnan Parthasarathi wrote:
>>> Currently, we need more attention to the way of working, in and with,
>>> the community and see how to increase the outreach of all the work we
>>> are doing, else we may induce estrangement in this space.
>> Yes. We could improve our engagement during design proposals.
>> Oftentimes, there
>> is an announcement style mail and then the commit.
> ..and more hangouts? Something like ceph developer summit (over
> hagnouts) would be good to have.
>> We should improve the way we target features for a release. We must
>> adopt a
>> merge-window style of development (e.g linux-kernel). Jeff had some
>> thoughts around
>> this. Time shouldn't be an excuse for hurrying up features into a
> Exactly. Something that's going on _now_ with the logging patches.
Good, let me make a few more statements about this example (considering
I put in *this* feature a *long* while back).
- Agree with Venky, that there is no call out in devel *now* to get
this done, and so there is a gap in understanding targets (for me as well)
- When this feature was put out and mails sent to devel there was
little to no traction (which is fine), but there was also little to no
comments on why this is good or bad, this does not help feature
development (esp. infra changes)
What I want to state is that, if there are changes that can impact other
components, we need better maintainer representation on comments and in
general bettering the solution, so that we get in all the requirements
straight and also deliver something that mostly does not need rework
later and solves the need well enough. We also need adoption plans in
other components, for such changes that cross component boundaries.
How can we better address this? (or are comments/suggestions already
addressing the same?)
P.S: I think we are starting to demonstrate sufficient interest in this
problem :) and that gives *me* great hope for the future...
NOTE: I am fine discussing specific features to enable problem
understanding/resolution better, than consider it mud slinging, just
>> More importantly, maintainers must be empowered to say _no_, when
>> submissions don't adhere to set expectations. Thoughts?
>> maintainers mailing list
>> maintainers at gluster.org
> maintainers mailing list
> maintainers at gluster.org
More information about the maintainers