[Gluster-devel] Proactive backports to release branches

[Vijay Bellur]

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