Open Stack

On Fri, Oct 16, 2015 at 5:32 PM, Kevin Benton <blak111 at 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.Fox at 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.magana at 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" <ihrachys at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151016/682f9f2e/attachment.html>