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? Some of these questions should be clearly answered in document IMO. Regards, Amar On Fri, Mar 17, 2017 at 11:55 PM, Amye Scavarda <[email protected]> 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 <[email protected]> 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 | [email protected] | Gluster Community Lead > > _______________________________________________ > Gluster-devel mailing list > [email protected] > http://lists.gluster.org/mailman/listinfo/gluster-devel > -- Amar Tumballi (amarts)
_______________________________________________ maintainers mailing list [email protected] http://lists.gluster.org/mailman/listinfo/maintainers
