Open Stack

On 05/23/2013 05:22 AM, Flavio Percoco wrote:
> Hi Guys,
>
> I've seen some patches that fix bugs that don't have any importance
> set. In some cases, it is difficult to determine what fixes are worth
> backporting without that information, that for, I was thinking that we
> should -1 those patches and ask for that information. Before doing
> going down that road, I wanted to know what you guys think about this
> and whether you've already talked about it.
>
> That information is relevant to determine whether the fix is worth for
> a stable branch, as noted in the StableBranch wiki[0].
>
> Cheers,
> FF
>
> [0] https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes

+1. I think bug importance should be a requirement, perhaps even
importance > Low or Medium.

This brings up another workflow issue.  Currently, *anybody* can tag a
bug for backport, set importance and propose a fix.  This gets added to
an already large pool of proposed patches and there is no way for stable
team reviewers to distinguish the critical fixes that many users are
waiting for vs. low priority nice-to-haves.   It would be great if we
could tighten the work flow and requirements a bit.  For
stable/grizzly,  I was thinking something like:

1. Bug gets 'Fixed Comitted' in master and tagged
grizzly-backport-potential. (LP bug shows it only affecting the project,
not grizzly release)
2. PTL/core-dev/stable-maint reviews bug:
 - opens bug task affecting Grizzly
 - sets importance in Grizzly accordingly
 - (maybe) targets toward milestone (2013.1.2)
 - (maybe) removes tag
3. Patch gets proposed to stable/grizzly for review and merge.  Patches
to stable branch require task/importance/milestone from #2.

We're currently doing step #2 post-merge and not until we're getting
ready to cut the point release.  I believe only certain team members
have access to set milestone (maybe target to release, too).  If that
work can happen as a required step before the patch gets proposed, we
can use it as a stamp of approval from core-devs/stable-maint that the
bug is appropriate for the stable branch.   Currently, that sort of
discussion and approval happens as +1s in code review but should be
happening in the bug itself before proposing patches, IMHO..

I *think* targeting the bug to milestone in step #2 would also make it
easier to track in-flight backports directly in LP. 

What do others thinks?

Cya,
Adam