On Fri, Oct 16, 2015 at 5:32 PM, Kevin Benton <blak...@gmail.com> wrote:
> We can't put in code and just hope for testing later. The tests are even > more important in back-ports because there could be unexpected differences > in the stable branch that make the patch not work correctly. > > However, we do need to make sure that people aren't complaining about the > testing methodology in the back-ports because it's too late for that. > I am quick to point out testing deficiencies so I hope I wasn't too tired and unknowingly did the unspeakable that which you speak of (I think people can fail to notice the branch the patch is submitted against). Reviewing a backport should be 90% about backport procedures: Does the commit message contain everything it should? Does the patch meet backport criteria? (Any DB, RPC, configuration or API changes? Is it a new feature or a high value / low risk bug risk? Will this somehow break users on upgrade?) A backport should be ideally identical to its master counterpart, so I agree that commenting on spelling mistakes, comments, code placement, design and the like should be avoided. If that bothers you so much, send a patch to master to fix the grave error you spotted! > > On Fri, Oct 16, 2015 at 2:23 PM, Fox, Kevin M <kevin....@pnnl.gov> wrote: > >> It would also help if the process could split out bug fixes from unit >> tests. I had a bug fix get stuck while the unit tests were bikesheded for a >> while, and then the delay of not getting quickly backported to the stable >> branches then kicked in. All the while I had to patch production clouds by >> hand with a non upstreamed fix. I'm all for having unit tests to ensure the >> bugs don't creep back in, but regression bugs should be fixed as quickly as >> possible. >> >> Thanks, >> Kevin >> ________________________________________ >> From: Edgar Magana [edgar.mag...@workday.com] >> Sent: Friday, October 16, 2015 2:04 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [neutron][stable] proactive backporting >> >> + 2 and total support for it. >> >> Looking forward to reviewing the first set of them. >> >> Edgar >> >> >> >> On 10/16/15, 5:33 AM, "Ihar Hrachyshka" <ihrac...@redhat.com> wrote: >> >> >Hi all, >> > >> >I’d like to introduce a new initiative around stable branches for >> neutron official projects (neutron, neutron-*aas, python-neutronclient) >> that is intended to straighten our backporting process and make us more >> proactive in fixing bugs in stable branches. ‘Proactive' meaning: don’t >> wait until a known bug hits a user that consumes stable branches, but >> backport fixes in advance quickly after they hit master. >> > >> >The idea is simple: every Fri I walk thru the new commits merged into >> master since last check; produce lists of bugs that are mentioned in >> Related-Bug/Closes-Bug; paste them into: >> > >> >https://etherpad.openstack.org/p/stable-bug-candidates-from-master >> > >> >Then I click thru the bug report links to determine whether it’s worth a >> backport and briefly classify them. If I have cycles, I also request >> backports where it’s easy (== a mere 'Cherry-Pick to' button click). >> > >> >After that, those interested in maintaining neutron stable branches can >> take those bugs one by one and handle them, which means: checking where it >> really applies for backport; creating backport reviews (solving conflicts, >> making tests pass). After it’s up for review for all branches affected and >> applicable, the bug is removed from the list. >> > >> >I started on that path two weeks ago, doing initial swipe thru all >> commits starting from stable/liberty spin off. If enough participants join >> the process, we may think of going back into git history to backport >> interesting fixes from stable/liberty into stable/kilo. >> > >> >Don’t hesitate to ask about details of the process, and happy >> backporting, >> > >> >Ihar >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Kevin Benton > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev