[Gluster-Maintainers] Lock down period merge process

[Nigel Babu]

On Tue, Aug 14, 2018 at 5:31 PM Shyam Ranganathan <srangana at redhat.com>
wrote:

> The intention is that master and release branches are always maintained
> in good working order. This involves, tests and related checks passing
> *always*.
>
> When this situation is breached, correcting it immediately is better
> than letting it build up, as that would entail longer times and more
> people to fix things up.
>
> In an ideal world, if nightly runs fail, the next thing done would be to
> examine patches that were added between the 2 runs, and see if they are
> the cause for failure, and back them out.
>

To be clear, at this point, we'll need to lock down master as well until
it's green again. If we know that master is broken, it's best we find the
culprit and back it out/land a fix. If it's backed out, the author has a
chance to fix the issue and re-land their patch. The problem with a broken
master is that we may break it yet again and it will be more difficult to
track down future failures.

This is more inconvenience, but this is what will help in the health of the
project long-term.



>
> Hence calling to backout patches is something that would happen more
> regularly in the future if things are breaking.
>
> Lock down may happen if 2 consecutive nightly builds fail, so as to
> rectify the situation ASAP, and then move onto other work.
>
> In short, what I wanted to say is that preventing lock downs in the
> future, is not a state we aspire for. Lock downs may/will happen, it is
> done to get the branches stable quicker, than spend long times trying to
> find what caused the instability in the first place.
>

Also adding a note that release branches have already been locked for a few
releases in case nobody has noticed. Only release managers can land to
release branches. This is done specifically so that the same process can
happen there as well.


-- 
nigelb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20180814/625cfc02/attachment.html>