[Gluster-Maintainers] Lock down period merge process

Amar Tumballi atumball at redhat.com
Fri Sep 28 04:25:19 UTC 2018

Top posting as I am not trying to answer any individual points!

It is my wish that we don't get into lock down state! But, there may be
times when it is needed! My take is, we will go with an approach which
works for majority of the cases, and when we get to it 1-2 times, lets do
another retrospective of events happened during the time when there was a
lock-down, and then improve further. Planning too much for future won't get
us any value at this time. We have bi-weekly maintainer meetings, where we
can propose changes, and get to solutions. None of this is written in
stone, so lets move on :-)


On Thu, Sep 27, 2018 at 8:18 PM Shyam Ranganathan <srangana at redhat.com>

> On 09/27/2018 10:05 AM, Atin Mukherjee wrote:
> >         Now does this mean we block commit rights for component Y till
> >         we have the root cause?
> >
> >
> >     It was a way of making it someone's priority. If you have another
> >     way to make it someone's priority that is better than this, please
> >     suggest and we can have a discussion around it and agree on it :-).
> >
> >
> > This is what I can think of:
> >
> > 1. Component peers/maintainers take a first triage of the test failure.
> > Do the initial debugging and (a) point to the component which needs
> > further debugging or (b) seek for help at gluster-devel ML for
> > additional insight for identifying the problem and narrowing down to a
> > component.
> > 2. If it’s (1 a) then we already know the component and the owner. If
> > it’s (2 b) at this juncture, it’s all maintainers responsibility to
> > ensure the email is well understood and based on the available details
> > the ownership is picked up by respective maintainers. It might be also
> > needed that multiple maintainers might have to be involved and this is
> > why I focus on this as a group effort than individual one.
> In my thinking, acting as a group here is better than making it a
> sub-groups/individuals responsibility. Which has been put forth by Atin
> (IMO) well. Thus, keep the merge rights out for all (of course some
> still need to have it), and get the situation addressed is better.
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers

Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20180928/1e32b73a/attachment-0001.html>

More information about the maintainers mailing list