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

Fri Mar 17 18:08:03 UTC 2017

On Fri, Mar 17, 2017 at 07:06:53PM +0100, Niels de Vos 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?
> 
> > ## 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.
> 
> > ## Definition of Owners + Peers

Also, what about the "Architects" we have in the GlusterFS project?
Should those not be mentioned in some way or form as well?

Niels

> > * 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?
> 
> > * 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?).
> 
> > * 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, ...).
> 
> > ## 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?
> 
> > * 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?
> 
> > * 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.
> 
> > ## 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.
> 
> > * 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?
> 
> > References:
> > https://www.mozilla.org/en-US/about/governance/policies/module-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.
> 
> Thanks!
> Niels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20170317/bec58790/attachment-0001.sig>