On Fri, Sep 28, 2018 at 9:56 AM Amar Tumballi <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> https://lists.gluster.org/mailman/listinfo/maintainers >> > > > -- > Amar Tumballi (amarts) > -- Pranith
_______________________________________________ maintainers mailing list [email protected] https://lists.gluster.org/mailman/listinfo/maintainers
