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