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 19:19:35 GMT


> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Tuesday, November 20, 2012 10:58 AM
> To: cloudstack-dev@incubator.apache.org
> Cc: Joe Brockmeier
> Subject: RE: [ACS401][DISCUSS] 4.0.1 Release dates & such
> 
> 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.
I failed to mention that if a member of the community wants a bug to be backported, they should
create the task not the release manager.  However, release manager can decide not to backport
(maybe due to the fix being too extensive or other reasons) by closing that task.
> - 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:david@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.Huang@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

Mime
View raw message