Open Stack

Being able to effectively track the bugs to be backported is a good idea.
This a example of an activity that can promoted to other projects through
best practices engineering management. Our hidden influencers can and
should include those that manage developers. We have only really focused on
product management up to this point.

Ideas on how we would start to communicate this kind of best practice
implemented?

Off the top of my head,
As an engineering manager of OpenStack developers, it would be ideal if I
could can
- get summary of best practices
- what's a normal day, week, month, release cycle look like for an average
project
- what are the minor and major events coming up

On Friday, October 16, 2015, Rochelle Grober <rochelle.grober at huawei.com>
wrote:

> Hey, folks!
>
> It appears that there are devs interested in improving the sustaining
> engineering situation in OpenStack.  I think we need to follow this thread
> and participate where we can add value.
>
> --Rocky
>
>
>
> -----Original Message-----
> From: Ihar Hrachyshka [mailto:ihrachys at redhat.com <javascript:;>]
> Sent: Friday, October 16, 2015 5:34 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [neutron][stable] proactive backporting
>
> 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
>


-- 
~sean