incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [ACS401][DISCUSS] 4.0.1 Release dates & such
Date Tue, 20 Nov 2012 17:51:55 GMT
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:chip.childers@sungard.com]
> Sent: Tuesday, November 20, 2012 7:29 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [ACS401][DISCUSS] 4.0.1 Release dates & such
> 
> On Mon, Nov 19, 2012 at 6:02 PM, Joe Brockmeier <jzb@zonker.net> 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
> > jzb@zonker.net
> > Twitter: @jzb
> > http://www.dissociatedpress.net/
> >

Mime
View raw message