On Sat, Mar 18, 2017 at 4:47 PM, Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx> wrote:
On Sat, Mar 18, 2017 at 1:20 AM, Amar Tumballi <atumball@xxxxxxxxxx> wrote:4. Can a component have more than 1 owner ? 1 maintainers etc?3. Who's responsibility is it to keep the gluster.org webpage? I personally feel the responsibility should be well defined.2. Should maintainers be responsible for answering ML / IRC questions (well, they should focus more on documentation IMO).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?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,AmarOn Fri, Mar 17, 2017 at 11:55 PM, Amye Scavarda <amye@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx | Gluster Community Lead_________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
--Amar Tumballi (amarts)
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
--Pranith
--
Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
