[Gluster-Maintainers] Lock down period merge process

[Atin Mukherjee]

tests/bugs/<component Y>/xxx.t failing can’t always mean there’s a bug in
component Y. It could be anywhere till we root cause the problem. Now does
this mean we block commit rights for component Y till we have the root
cause? That doesn’t make much sense right? This is one of the reasons in
such case we need to work as a group, figure out the problem and fix it,
till then locking down the entire repo for further commits look a better
option (IMHO).

On Thu, 27 Sep 2018 at 14:04, Nigel Babu <nigelb at redhat.com> wrote:

> We know maintainers of the components which are leading to repeated
>> failures in that component and we just need to do the same thing we did to
>> remove commit access for the maintainer of the component instead of all of
>> the people. So in that sense it is not good faith and can be enforced.
>>
>
> Pranith, I believe the difference of opinion is because you're looking at
> this problem in terms of "who" rather than "what". We do not care about
> *who* broke master. Removing commit access from a component owner doesn't
> stop someone else from landing a patch will create a failure in the same
> component or even a different component. We cannot stop patches from
> landing because it touches a specific component. And even if we could, our
> components are not entirely independent of each other. There could still be
> failures. This is a common scenario and it happened the last time we had to
> close master. Let me further re-emphasize our goals:
>
> * When master is broken, every team member's energy needs to be focused on
> getting master to green. Who broke the build isn't a concern as much as
> *the build is broken*. This is not a situation to punish specific people.
> * If we allow other commits to land, we run the risk of someone else
> breaking master with a different patch. Now we have two failures to debug
> and fix.
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>
-- 
- Atin (atinm)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20180927/56cd0757/attachment.html>