On Thu, Jun 29, 2017 at 10:58 AM, Amar Tumballi <atumball@xxxxxxxxxx> wrote:
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.All,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.
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.
[1] - https://review.gluster.org/17583
[2] - http://lists.gluster.org/mailman/listinfo/maintainers
Thanks everyone. This activity is now complete. I have also raised a bug to get the merge access to relevant maintainers on their components [3].
Every new maintainers, please make a note to become member of the mailing list mentioned above this week, so you all can participate in the bi-weekly maintainers' meeting.
Regards,
Amar
AmarWrite back if you have any more concerns.Regards,On Tue, Apr 18, 2017 at 2:27 PM, Michael Scherer <mscherer@xxxxxxxxxx> wrote:______________________________There is also the overall issue iof documentation consistency. ForLe 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.
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)
--
Amar Tumballi (amarts)
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
