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@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
