On Sat, Mar 18, 2017 at 4:47 PM, Pranith Kumar Karampuri < [email protected]> wrote:
> > > On Sat, Mar 18, 2017 at 1:20 AM, Amar Tumballi <[email protected]> > 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 <[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) >> >> _______________________________________________ >> Gluster-devel mailing list >> [email protected] >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> > > > > -- > Pranith > -- Pranith
_______________________________________________ Gluster-devel mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-devel
