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.
Here's what I posted. I realized I talked about cherry-picking but this process is also good for fixing bugs. "We should make use of the Jira functionalities. These steps can be performed by everyone. - A bug is filed in issues.apache.org/cloudstack. This should target the releases that it is to be fixed in. - If the bug needs to be propagated to another release, a subtask is created for that release. The release manager decides on whether the bug should be put into the release. Upon which he can do the following things. - The bug shouldn't be in the release, then resolve the sub-task with reason why it is not in the release. - The bug should be in, release manager either assigns to the developer to cherry-pick or cherry-picks himself. The person doing the cherry-pick then does the following: - The commit message for the bug should include the subtask's bug id and not the original bug's id. - Once the cherry-pick is done, commit id should be placed with the sub task and the sub-task is resolved. There's a lot of benefits to this. The primary is that there's a trail on where the fixes went. It's also an official channel of communication between demand on where the bug is fixed, release manager, and developer. I like to ask that release managers do not accept a bug as resolved until the commit id has been put into the bug. I like to have this done automatically by git but I understand there's pushback on adding git-hooks to apache infra. Although, apache should really adopt this practice for all projects. It's a life-save when trying to figure out how a bug is fixed." --Alex > -----Original Message----- > From: Chip Childers [mailto:[email protected]] > Sent: Tuesday, November 20, 2012 7:29 AM > To: [email protected] > Subject: Re: [ACS401][DISCUSS] 4.0.1 Release dates & such > > On Mon, Nov 19, 2012 at 6:02 PM, Joe Brockmeier <[email protected]> wrote: > > Hi all, > > > > I've started working on 4.0.1 and put together this page on the wiki to > > track progress, etc.: > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.0.1 > -incubating+Release > > > > Please follow up this thread or edit the wiki with any bugs that are > > fixed & belong in the 4.0.1-incubating release. > > I'd suggest using Jira's fix version field actually, that way you can > have a real-time view of what the state of the release is. The wiki > page will be hard to keep up to date, and probably isn't needed for > feature related discussions. Also remember that bugs can have > multiple fix versions identified. So if the fix is done in master, > then cherry-picked to the 4.0 branch, it can have a fix version of > 4.0.1 and 4.1.0. > > I'd also suggest adding CLOUDSTACK-524 (just opened) to the bug-fix > release target, depending on the scope of the fix (i.e.: change risk > and effort involved). > > > Right now, I'm planning to freeze 4.0.1 on November 30th and call for > > testing from 11/30 to 12/8, calling for a vote on 12/8. > > Sounds about right! I think that it's probably best to stick with > that schedule, and just release whatever gets fixed as the release. > We may need a second bug-fix release (or more) before 4.1.0 anyway. > > > Thoughts, comments, flames, tips for a delicious turkey and stuffing? > > > > Best, > > > > Joe > > -- > > Joe Brockmeier > > [email protected] > > Twitter: @jzb > > http://www.dissociatedpress.net/ > >
