[Gluster-devel] Proactive backports to release branches

[Niels de Vos]

On Thu, Jan 15, 2015 at 10:49:44AM +0530, Atin Mukherjee wrote:
> 
> 
> On 01/14/2015 04:44 PM, Vijay Bellur wrote:
> > On 01/14/2015 04:34 PM, Vijay Bellur wrote:
> >> Hi All,
> >>
> >> We have been normally following a reactive process to backport patches
> >> to release branches. The backport guidelines page [1] describes it in
> >> more detail. Given the rate at which our master branch moves, I think it
> >> is becoming hard for users to identify which patch(es) can potentially
> >> fix problems being faced in their deployments. I have also heard a
> >> similar problem reported by release maintainers about not being able to
> >> cherry pick patches from master to respective releases as the backports
> >> could be non-trivial in nature. Overall this can lead us to do minor
> >> releases not having the right content from a stability & usability point
> >> of view.
> >>
> >> I have been thinking about this problem and here are some solutions that
> >> crossed my mind:
> >>
> >> 1. Developers become more pro-active in backporting patches to release
> >> branches.
> IMO this should be the best approach, developers need to be more
> proactive to assess the importance of the patch and ensure they are
> getting backported. I think it will be really tedious and harsh for a
> release maintainer or even a component maintainer to follow up each and
> every patches going into master and decide whether they are candidates
> for backport.

Indeed. I am of the opinion that this should be one of the
checks/considerations that get applied when a change gets reviewed.

> ~Atin
> >>
> >> 2. Release maintainers open a patch acceptance window from component
> >> maintainers for every minor release. component owners can nominate
> >> patches for inclusion in a minor release and work with respective
> >> developers to have those patches backported.

I do not think this would help much. The number of outstanding patches
for stable releases is not that big. At least for 3.5 I tend to merge
changes when they have been reviewed sufficiently, I do not really care
about a Linux kernel style 'merge window'.

If you have a convincing argument on 'why' it would help, I might change
my mind.

> >> 3. Component maintainers notify release maintainers about important
> >> patches when they merge it on master. Release maintainers can then work
> >> with developers & component maintainers to have the backports in a minor
> >> release.

Component maintainers or developers should not 'notify release
maintainers', they should just clone the related bug for the other
versions that are affected. Release maintainers should get notified
automatically that way (or at least in their regular check for new bugs
against the version they maintain).

> >> 4. We nominate serious bugs as release blockers during our weekly bug
> >> triage and ensure that these bugs get addressed for a minor release.

Our Bug Triage Guidelines [2] already suggest to clone the bug for different
versions. If a developer files a bug for a patch, they should apply the
Triage Guidelines to their own new bug and think about the need for
backports.

> >> We might end up needing a combination of these and other ideas to make
> >> the minor releases contain the right content for our users. Your
> >> thoughts and ideas on addressing this problem would be very welcome.
> >>
> >> Once there is consensus, I will be happy to document this process on
> >> gluster.org.

I'm in agreement on points 1, 3 and 4 of your list. It would be really
good to get backports as soon as a bug in the master branch has been
identified and fixed. There are regular occasions where a user reports a
bug against a stable version, and the fix is already months available,
it just was never (suggested for) backported/ing.

Doing a backport of a patch for the master branch tends to be easy and
quick when done immediately. When needing to do a backport months later
(possibly by someone else), is often much harder.

Thanks,
Niels


> >> Thanks,
> >> Vijay
> > 
> > and adding the missing link:
> > 
> > [1]
> > http://www.gluster.org/community/documentation/index.php/Backport_Guidelines

[2] http://www.gluster.org/community/documentation/index.php/Bug_triage
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150121/e8f3bfad/attachment.sig>