Re: [Gluster-Maintainers] Maintainers 2.0 Proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



All,

Thanks for participating actively in the discussions. With all your co-operation we now have a update on maintainers 2.0 proposal. Vijay Bellur sent a patch last week [1] capturing all the discussions.

Please go through the patch and see if you have any more concerns. There are many new names in there, so just review it so you can Ack it. Niels (ndevos) added all the people with their name on maintainers file as reviewers for the patch. Please take some time today and give +1 to it to acknowledge you are aware of the responsibilities. After 20 or more +1 on the patch, we will merge the patch, and accordingly raise a ticket to update the access to merge rights etc.

Also, if your name is added in maintainers list (even as peer for component), please become member of Maintainers mailing list [2] This list is an open list (all archives available for anyone to read) so make sure you subscribe and become members.  Make sure you update your calendars with maintainer meeting timings, so you can attend it.

[1] - https://review.gluster.org/17583
[2] - http://lists.gluster.org/mailman/listinfo/maintainers

Main maintainers 2.0 proposal link: https://hackmd.io/s/SkwiZd4qe

Write back if you have any more concerns.

Regards,
Amar



On Tue, Apr 18, 2017 at 2:27 PM, Michael Scherer <mscherer@xxxxxxxxxx> wrote:
Le mardi 18 avril 2017 à 10:25 +0200, Niels de Vos a écrit :
> On Mon, Apr 17, 2017 at 04:53:55PM -0700, Amye Scavarda wrote:
> > On Fri, Apr 14, 2017 at 2:40 AM, Michael Scherer <mscherer@xxxxxxxxxx>
> > wrote:
> >
> > > Le jeudi 13 avril 2017 à 18:01 -0700, Amye Scavarda a écrit :
> > > > In light of community conversations, I've put some revisions on the
> > > > Maintainers changes, outlined in the hackmd pad:
> > > > https://hackmd.io/s/SkwiZd4qe
> > > >
> > > > Feedback welcomed!
> > > >
> > > > Note that the goals of this are to expand out our reach as a project
> > > > (Gluster.org) and make it easy to define who's a maintainer for what
> > > > feature.
> > > > I'll highlight the goals in the document here:
> > > >
> > > > * 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
> > > >
> > > > We've clarified what the levels of 'owners' and 'peers' are in terms of
> > > > responsibility, and we'll look to implement this in the 3.12 cycle.
> > > > Thanks!
> > >
> > > So, I realize that the concept of component is not defined in the
> > > document. I assume everybody have a shared understanding about what it
> > > is, but maybe not, so wouldn't it make sense to define it more clearly ?
> > >
> > > Is this planned to be done later as part of "We will be working on
> > > carving out new components for things that make logical sense." ?
> > >
> > > As for example, with regard to my previous comment, would
> > > "infrastructure" be a component, would "documentation" be a component ?
> > >
> > > My understanding is that there's a working spreadsheet being refined to
> > sort out what's an area that needs a maintainer defined, and what's
> > something that maybe doesn't need a named maintainer. Documentation is a
> > tricky place to get to, because that's something that you do just naturally
> > so that future-you doesn't hate current-you.
>
> I agree that documentation should be part of the standard development
> workflow. Unfortunately, this is not something that gets done without
> reminding everyone about it. We still need maintainers/owners to bug
> developers for documentation of new features, monitor the pull-request
> queue and decide if the documentation is written in an acceptible way.

There is also the overall issue iof documentation consistency. For
example, style, glossary, etc, all kind of stuff that shouldn't be per
component but aligned overall.

> The maintenance of the gluster.readthedocs.io site might be a
> infrastructure task?

Wouldn't it be more logical to have it managed by the people that did
champion RTD ? I am unable to find the discussions about it, but I am
quite sure I had some concerns regarding RTD and wouldn't volunteer to
maintain something where I had objections (such as "being unable to fix
anything" is quite high on my usual objection list for taking
responsibility of a piece of infra)
--
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS



_______________________________________________
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

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux