On Sat, Mar 18, 2017 at 1:20 AM, Amar Tumballi <atumb...@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. > > Some of these questions should be clearly answered in document IMO. > > Regards, > Amar > > > On Fri, Mar 17, 2017 at 11:55 PM, Amye Scavarda <a...@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 <nde...@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 | a...@redhat.com | Gluster Community Lead >> >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> > > > > -- > Amar Tumballi (amarts) > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel > -- Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel