> On 16 Oct 2015, at 17:36, Salvatore Orlando <[email protected]> wrote: > > This sounds like a pretty decent idea to me. Considering Neutron's patch > merge rate this activity should hopefully not take a consistent chunk of your > Friday.
Actually, it does, if you consider other stable maintenance activities like reviewing existing stable backports in all stadium projects (side note: I believe it should not be the sole neutron-stable-maint members responsibility but subprojects should get their stable cores); tracking stable gate state; now walking thru bugs mentioned in commit messages. I would say, it takes ~2h each week to keep up. But that’s not a big deal, just wanted to give clue. > It might also make sense to ask contributors to resume the habit of tagging > bugs with 'backport-potential' even if not in the RC period. > Yes. Is it even bound to RC period now? I didn’t think so. Tracking the stable backport tags and moving them from -backport-potential to -in-<release> tags is another thing I want us to do consistently (that would be another element in the process after we are settled with proactive backporting). > I am glad to offer my help as well in evaluating "backport worthiness", and > the process you outlined looks very good to me. > If there's any discussion needed for assessing whether a bug fix should be > backported or not, we could either use the etherpad or launchpad, with a > slight preference for launchpad. Probably links to bugs for discussion in the etherpad and actual discussion in LP? Another alternative is having a separate tag for bugs with unclear backporting status. Ihar
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
