Actually it's designed to handle the situation you're talking about. The process means
- bug itself is always for the master branch. - fixed version is insufficient to indicate why a bug should be fixed in a certain branch. An en - release manager should triage and indicate what goes into a branch by creating tasks - users and developers can indicate why they need a bug fixed in a branch by creating tasks and give a reason. - release manager can easily manage a release by looking at the completion of those tasks. - Resolving a task doesn't mean the bug got resolved. A bug is only resolved when the fixed is cherry-picked to master. It's a easy way to keep track of what got propagated. So for example in this case. A bug is fixed in master. 4.0.1 is branched from 4.0 so it doesn't have these fixes. So what we can do is this. - Create a search for all bugs fixed in master since 4.0 was branched and there's no sub task indicating it's been already fixed in 4.0 - Asked the community to review the list of bugs and indicate what should be back ported. - Release manager goes through P1 and P2 bugs and checks whether or not they should be back ported. - Create a task for all bugs that should be backported. - Track the bugs through that list. --Alex > -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Tuesday, November 20, 2012 10:00 AM > To: cloudstack-dev@incubator.apache.org > Cc: Joe Brockmeier > Subject: Re: [ACS401][DISCUSS] 4.0.1 Release dates & such > > On Tue, Nov 20, 2012 at 12:51 PM, Alex Huang <alex.hu...@citrix.com> > wrote: > > Sometime ago I suggested a process for doing this. Have we considered > that process and decided it's not useful? I think that process is much easier > to maintain than a list on the wiki. > > > This process is good to adopt going forward - the problem with it is > two fold, though: > > * Many of those bugs were fixed without knowledge that there would be > a 4.0.1 - and so many have 4.1.0 as their fix version. > * Many bugs have no targeted fixed version - or in some cases have > multiple which is even more confusing. > > I think there probably needs to be a more active triaging of bugs by > folks doing release management, and maybe some consensus about what > needs to go where. I am somewhat concerned about the person filing > bugs needing to make that initial determination of whether the fix > should be in x.x.+1 or x.+1.x, etc. > > Speaking of, I'll go look into tickets with no fix version set. > > --David
