On Tue, Nov 20, 2012 at 12:51 PM, Alex Huang <[email protected]> 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. > > 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.
I was good with this process when you first sent it out, but then I remembered that the fixVersion and affectsVersion fields are multi-value. I think we need to do both. Bugs are the records that we should put into release notes, while tasks are the tracking items to help us understand if something is done for a particular branch. My only concern is that the task-based approach (as opposed to simply using the multi-value nature of affects and fix version fields) is the level of effort required to maintain multiple Jira records. Joe, do you want to give it a shot using tasks and we'll see if that's sustainable? > 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/ >> > >
