[Gluster-Maintainers] [Gluster-devel] Maintainers 2.0 Proposal

Sat Mar 18 11:19:21 UTC 2017

On Sat, Mar 18, 2017 at 4:47 PM, Pranith Kumar Karampuri <
pkarampu at redhat.com> wrote:

>
>
> On Sat, Mar 18, 2017 at 1:20 AM, Amar Tumballi <atumball at redhat.com>
> wrote:
>
>> I don't want to take the discussions in another direction, but want
>> clarity on few things:
>>
>> 1. Does maintainers means they are only reviewing/ merging patches?
>> 2. Should maintainers be responsible for answering ML / IRC questions
>> (well, they should focus more on documentation IMO).
>> 3. Who's responsibility is it to keep the gluster.org webpage? I
>> personally feel the responsibility should be well defined.
>> 4. Can a component have more than 1 owner ? 1 maintainers etc?
>>
>
> More than 1 maintainer is the best case we should aim for. I see EC
> benefit tremendously because of this. Work keeps moving because at least
> one of Xavi/I are available for discussions.
>

If for some reason we decide we should have only one maintainer, I would
like to be peer for EC and Xavi should be maintainer.

>
>
>>
>> Some of these questions should be clearly answered in document IMO.
>>
>> Regards,
>> Amar
>>
>>
>> On Fri, Mar 17, 2017 at 11:55 PM, Amye Scavarda <amye at redhat.com> wrote:
>>
>>> Posting in line, but it may be pretty hard to follow.
>>> Apologies if I miss something.
>>>
>>> On Fri, Mar 17, 2017 at 11:06 AM, Niels de Vos <ndevos at redhat.com>
>>> wrote:
>>>
>>>> On Wed, Mar 15, 2017 at 10:12:18PM -0400, Vijay Bellur wrote:
>>>> > Hi All,
>>>> >
>>>> > We have been working on a proposal [1] to make the lifecycle
>>>> management of
>>>> > Gluster maintainers more structured. We intend to make the proposal
>>>> > effective around 3.11 (May 2016).
>>>> >
>>>> > Please review the proposal and let us know your feedback. If you need
>>>> > clarity on any existing aspect or feel the need for something
>>>> additional in
>>>> > the proposal, please feel free to let us know.
>>>>
>>>> I'll just include the proposal here and add inline comments. I'm not
>>>> sure if this is the best way, or if you would like anyone edit the
>>>> document directly...
>>>>
>>>> > Thanks!
>>>> > Amye & Vijay
>>>> >
>>>> > [1]  https://hackmd.io/s/SkwiZd4qe
>>>>
>>>>
>>>>
>>>> > # Revised Maintainers for 3.11
>>>> >
>>>> > AI from Community Meeting, March 1:
>>>> > amye to work on revised maintainers draft with vbellur to get out for
>>>> > next maintainer's meeting. We'll approve it 'formally' there, see how
>>>> it
>>>> > works for 3.11.
>>>>
>>>> The next maintainers meeting happens when many maintainers are at VAULT.
>>>> I would not expect a large attendance at that time. Also, Amye sent an
>>>> email with a different target date?
>>>>
>>>
>>> Feedback target date of 30 days, that's what I was indicating. This was
>>> reviewed in the maintainers' meeting on March 8 and we're now expanding out
>>> to the larger group.
>>>
>>>>
>>>> > ## Goals:
>>>> > * Refine how we declare component owners in Gluster
>>>> > * Create a deeper sense of ownership throughout the open source
>>>> project
>>>> > * Welcome more contibutors at a project impacting level
>>>>
>>>> It would be good to make a distinction between the Gluster Community and
>>>> the GlusterFS Project. "Gluster" refers in my understanding to all the
>>>> projects of the Gluster Community. This document looks most aimed at the
>>>> GlusterFS project, with some Gluster Community references.
>>>
>>>
>>>
>>> Is this distinction relevant? We're talking about how we define a
>>> maintainer for contributing to the Gluster community overall. As I work
>>> through this, I see your confusion. I don't think that we'd be able to make
>>> this call for 'all related projects', but for committing back into Gluster
>>> proper, yes.
>>>
>>>
>>>>
>>> > ## Definition of Owners + Peers
>>>> > * Commit access to the project is not dependent on being a
>>>> maintainer. A
>>>> >   maintainer is a leadership role within the project to help drive the
>>>> >   project forward.
>>>>
>>>> "the project", is that the glusterfs git repository, or any repository
>>>> that we maintain? How would we see this for projects that contain
>>>> Gluster modules like NFS-Ganesha and Samba? Or are those not considered
>>>> as "our" components?
>>>
>>>
>>> I think initially, we'd want to limit this to just the Gluster project.
>>> Too much expansion and we'll have too much change too quickly.
>>>
>>>
>>>>
>>> > * Owner - Subject matter expert, help design large feature changes and
>>>> >   decide overall goal of the component. Reviews patches, approves
>>>> >   changes. Responsible for recruiting assisting peers. Owner of
>>>> >   component. (Principle Software Engineer - unconnected to actual role
>>>> >   in Red Hat organization)
>>>>
>>>> I would say a "subject matter expert" can give a +2 code-review in
>>>> Gerrit, and the "owner" of the component would honour that opinion. I
>>>> fail to see what "Principle Software Engineer" has to do with this if it
>>>> is not connected to a role at Red Hat (hmm, I need to talk to my boss?).
>>>>
>>>>
>>> I've gotten feedback that we should revisit the 'Principal' vs 'Senior'
>>> framing - apologies. It was not the intention to make it Red Hat centric in
>>> this way, but it was shorthand for responsibility areas. I'm happy to
>>> revisit.
>>>
>>>
>>>> > * Peer - assists with design, reviews. Growing into subject matter
>>>> >   expert, but not required to be engaged in the overall design of the
>>>> >   component. Able to work largely without day-to-day supervision.
>>>> >   (Senior Software Engineer -  unconnected to actual role in Red Hat
>>>> >   organization)
>>>>
>>>> A "peer" would do code-review +1 on the proposed design and/or change.
>>>> That means it still needs a "subject matter expert" to really approve
>>>> the change. Hopefully all the straight forward points have been checked
>>>> by peers for changes (coding style, basic error checking and resource
>>>> allocation/freeing, test-case, ...).
>>>>
>>>> Correct. This person could also be your backup for making sure the
>>> feature moves forward!
>>>
>>>
>>>> > ## Additional changes:
>>>> > * Carving out new components needs Project Lead + Community lead
>>>> >   approval  - we can expand this as needed.
>>>>
>>>> Yes, please expand. Are new projects (like the recent gluster-block) new
>>>> components? Who is/are Project Lead and Community Lead, are these the
>>>> same people for all projects in the Gluster Community?
>>>>
>>>
>>> Expand meaning - as we adopt this for Gluster project. Not including
>>> 'all the various connected projects'. Too far for this particular rollout.
>>>
>>>>
>>>> > * Project Lead and Community Lead should watch out for people owning
>>>> >   lots of components with no peers. This may lead to burn out.
>>>> Identify
>>>> >   these owners and assist them in getting new peers.
>>>>
>>>> This means that for the GlusterFS project the MAINTAINERS file needs to
>>>> be maintained very well. How do you plan to keep track of all the other
>>>> related projects?
>>>
>>>
>>> The maintainers file does need to be regularly reviewed and updated.
>>> Think of it like the 'phone tree' for the project.
>>>
>>>> > * Owners can pick peers for their components with just an
>>>> announcement.
>>>>
>>>> I do not think "peers" should need approval. Is not everyone allowed to
>>>> review designs and patches? Sending an announcement for new contributors
>>>> that just reviewed their first patch does not sound scalable. New
>>>> "peers" can review proposals for any component. I must be missing
>>>> something here, a better explanation would be most welcome.
>>>>
>>>> We'll need to know who we'd go to for a backup. A peer would be someone
>>> you'd trust to be able to maintain a feature in your absence. Better
>>> clarification?
>>>
>>> > ## Transition
>>>> > * Current maintainers get to choose between ownership/peer of
>>>> components
>>>> >   they're listed as owners.
>>>>
>>>> Well, yes, hopefully everyone being an "owner" or "peer" does so
>>>> voluntary. Obviously certain companies have an interest in getting their
>>>> employees to volunteer to do the work (and hopefully the tasks are part
>>>> of their official job).
>>>
>>>
>>>> > * Have people focus on maximum of two components as an owner. If they
>>>> >   have more, they should be strongly suggested to invite new people as
>>>> >   peers to be trained as future owners. If current owners consider
>>>> >   somebody as being ready to take over as owner of a component that
>>>> they
>>>> >   are managing, please announce new owners with appropriate
>>>> >   justification on maintainers ML.
>>>>
>>>> Why two components? The majority of people listed in the glusterfs
>>>> MAINTAINERS file already have more. And that is only for the glusterfs
>>>> project, many will  have additional projects they are responsible for.
>>>>
>>>> We started with two to see how many people will be affected by this -
>>> just limiting to Gluster.
>>>
>>>
>>>> > * It's okay to drop a component if they are not able to find
>>>> >   time/energy. Owners are requested to minimize disruption to the
>>>> >   project by helping with transitions and announcing their intentions.
>>>>
>>>> Yes, of course :)
>>>>
>>>> > * Project Lead and Community Lead are responsible for maintaining the
>>>> >   health of the community. This includes balancing work for component
>>>> >   owners or choosing which components aren't included in the cycle in
>>>> a
>>>> >   way that minimizes disruption to the project.
>>>>
>>>> What "cycle" is meant here?
>>>>
>>>
>>> Release cycle.
>>>
>>>
>>>>
>>>> > References:
>>>> > https://www.mozilla.org/en-US/about/governance/policies/modu
>>>> le-ownership/
>>>> > https://www.drupal.org/dcoc
>>>>
>>>> Maybe also see how QEMU and the Linux kernel handle this? I'm definitely
>>>> more familiar with those projects than Mozilla or Drupal.
>>>
>>>
>>> Want to add in more detail from those? These were the initial references
>>> from where I'd started, happy to see if there are features from other
>>> communities.
>>>
>>>>
>>>>
>>> Thanks!
>>>> Niels
>>>>
>>>
>>>
>>>
>>> --
>>> Amye Scavarda | amye at redhat.com | Gluster Community Lead
>>>
>>> _______________________________________________
>>> Gluster-devel mailing list
>>> Gluster-devel at gluster.org
>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Amar Tumballi (amarts)
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Pranith
>

-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20170318/b8fc1f6c/attachment-0001.html>