cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Animesh Chaturvedi <animesh.chaturv...@citrix.com>
Subject RE: Call for 4.2 and 4.1.1 Release Managers!
Date Mon, 01 Apr 2013 22:47:39 GMT


> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Wednesday, March 27, 2013 7:20 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Call for 4.2 and 4.1.1 Release Managers!
> 
> On Wed, Mar 27, 2013 at 01:00:52PM -0400, David Nalley wrote:
> > On Thu, Mar 21, 2013 at 4:09 PM, Musayev, Ilya <imusayev@webmd.net>
> wrote:
> > > Chip
> > >
> > > Would you please collaborate as to what release manager does. An
> examples would be nice.
> > >
> > > Thanks
> > > ilya
> >
> >
> > Hi Ilya:
> >
> > So the short description is 'cat herder'
> >
> > The real tasks/duties - assuming a feature release:
> >
> > Act as the release schedule reminder - effectively driving and
> > enforcing the dates we agreed to earlier in the release cycle.
> > Triage/manage the bugs/new features coming into a feature release,
> > ensuring the severity is set appropriately and drawing attention to
> > things that get ignored/dropped.
> > Calling for votes
> > Creating releases (and signing, and getting them uploaded and
> > mirrored) Acting as change control when we start locking down a branch
> > for release - essentially ensuring that changes after a certain period
> > get some minimum level of review and testing, and that we aren't
> > deviating from that. Chip has called himself the human gerrit because of this.
> >
> >
> > The point releases are a bit different - there are no new features,
> > and you really are trying to focus on bugfixes, so point releases
> > should be a bit less work. Experience has shown that most folks aren't
> > as happy to fix bugs as to develop new features. So you become much
> > more of a 'attention seeker' - or perhaps 'attention driver' is a
> > better word. - driving attention to things that need to be fixed. It
> > also means spending copious amounts of time in Jira (as you would in a
> > feature release, but this is even more pervasive) You essentially have
> > to look at bugs reported against newer releases and see if they apply
> > - if patches for them are applicable to your release (e.g. if I fix a
> > bug for 4.2 - does that bug apply to 4.1? Should the fix be in 4.1.1?)
> > etc.
> >
> > --David
> >
> 
> So with David's description (thanks BTW, it's been a loooong $dayjob week for
> me already), we have one volunteer in Animesh (and Animesh, does your offer
> still stand?).  Anyone else want to take a crack at it?
> 
[Animesh>] Chip my offer is still on. Like Ilya I also have some ambiguity or unknowns
on release management, I am thinking of putting together a wiki page on release management
tasks and responsibilities, and we can collaborate on refining it. By the way I feel given
that CloudStack is a big project there can be more than one person help coordinate release
activities. 

> -chip

Mime
View raw message