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.
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
and adding the missing link:
[1]
http://www.gluster.org/community/documentation/index.php/Backport_Guidelines
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
