[Gluster-devel] Proactive backports to release branches

Vijay Bellur vbellur at redhat.com
Wed Jan 14 11:04:32 UTC 2015


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.

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.

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.

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

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.

Thanks,
Vijay


More information about the Gluster-devel mailing list