[Gluster-Maintainers] Proposal for keeping the release-* branches more stable

[Kaushal M]

On Fri, Apr 1, 2016 at 2:18 PM, Niels de Vos <ndevos at redhat.com> wrote:
> It seems that we are very eager on backporting things to release-3.7 and
> hopefully also release-3.6 and release-3.5. As maintainers we have the
> duty to keep the stable branches stable. We regulary introduce
> regressions by backporting changes that were not fully backed in the
> master branch. The most recent one being the broken 'make dist' tarball
> that would prevent users and distributions from packaging 3.7.10.
>

This happened because of Jenkins failing to report back complete status.
The rpmbuild jobs were failing for upto 2 days, but no one noticed as
the failures  weren't reported back.
We are right now attempting to fix this reporting.

Even though I spent a lot of time on Jenkins yesterday, I didn't
notice these failures because it got lost in the sea of RED statuses.
This is convinces me that we need to make our tests more reliable.
Seeing RED statuses all the time makes us complacent.
IMO, we should spend dedicated time to just fix these tests. We should
even stop merging new changes till this is done.


> I am of the opinion that we need more strict guidelines for backports,
> so that the stable branches do not break as often as is happening now.
> One of the options is that we only backport changes that have been in
> the master branch for X days. We're working on adding more nightly
> testing of the master branch and this hopefully catches mistakes early,
> before someone does a backport.

I agree that we need to frame stricter guidelines for backports.

Ideally, I'd like it if only the release-maintainer were allowed to
merge changes.
This way, they would always know what was happening in the branch.
But this would be too much work for 1 person considering the volume of
changes we get now.

As an alternative, I'd suggest that during the release window (the
days or the week surrounding the scheduled release-date),
only the maintainer is merge changes. This will help them be on top
any potential breakages.
This would help avoid situations like yesterday, where the change got
merged without my knowledge.

>
> We could even investigate how to add a 'zero-day-tested' flag in Gerrit
> after the tests successfully run.
>
> I would like to hear the opinion of ALL maintainers on this list. We
> need maintainers to be responsive to emails here, see it as a test :-)
>

This is something we need more of. Not enough maintainers take part in
community activities.
I see a lot of maintainers only being involved in technical discussions.
While technical discussions are important, it is also important that
maintainers as leaders in the community,
also take part in maintaining the community as well.

> Thanks,
> Niels
>
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
>