[Gluster-devel] Proactive backports to release branches

[Atin Mukherjee]

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.

~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.
>>
>> 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 at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel