[Gluster-devel] Updating Maintainers Guide

[Atin Mukherjee]

Few comments/suggestions from my side:

1. Under the section of "Guidelines that Maintainers are expected to
adhere to" point 3 describes the following:

"The responsibility of merging a patch into a release branch in normal
circumstances will be that of the release maintainer's. Only in
exceptional situations, maintainers & sub-maintainers will merge patches
into a release branch."

I don't think this can  work out well for the most active branch as the
volume of number of backports is pretty high and depending on a single
release manager to get those patches in would add significant delay. So
my proposal is to stick to "release manager only merging patches" scheme
to branches apart from the most active one and for the active one
responsibility is on both release manager and sub maintainers.

2. Component health monitoring

I think the above is missing. Sub maintainers should also need to keep a
close eye on the incoming bugs and triage them (When I say triage, its
not only setting TRIAGED in the keyword but assigning the bugs to right
people, setting the right level of priority/severity and updating the
RCA once its available)

3. Bug status correctness

Although this is the bug owner's responsibility, but maintainers should
proactively move the bug to the correct status. Most of the time I've
seen a bug not been moved to MODIFIED from POST once its merged.
Probably maintainer can take up the responsibility too post merging the
patch.

4. Plan for the coming release

Is it worth that maintainers also should share a report on the bugs/RFEs
to be worked on for the upcoming release?

5. Community meeting hosting

I have been pushing hard on this to start a rotational policy on hosting
the community meeting. Point 5a in the document says "Facilitate the
community in all aspects." and I assume this covers the same aspect as
well, if not we can add this point separately too.

~Atin

On 03/02/2016 07:17 PM, Kaushal M wrote:
> Hello maintainers!
> 
> If you didn't know, we have a maintainers guide at [1]. This document
> describes what is expected from a GlusterFS maintainer, and is a quick
> guide on maintainer-ship.
> 
> But this document is very light at the moment, and can be improved.
> So, I'd like to know what other information can be added to the doc.
> I'll start.
> 
> - Properly describe the responsibilities of different types of
> maintainers; sub-maintainers, release-maintainers etc.
> - Define the process for becoming a maintainer (Neils came up with
> this actually)
> 
> Please go through the document and reply with your opinions.
> 
> Thanks,
> Kaushal
> 
> [1] https://gluster.readthedocs.org/en/latest/Contributors-Guide/Guidelines-For-Maintainers/
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>