[Gluster-Maintainers] Lock down period merge process

[Pranith Kumar Karampuri]

On Fri, Sep 28, 2018 at 9:56 AM Amar Tumballi <atumball at redhat.com> wrote:

> 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 :-)
>

I think the discussion has been productive so far. There are some good
suggestions. So let us come to some conclusion and move ahead.


>
> -Amar
>
>
> On Thu, Sep 27, 2018 at 8:18 PM Shyam Ranganathan <srangana at redhat.com>
> wrote:
>
>> 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)
>


-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20181003/c632e9b4/attachment-0001.html>