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: [DISCUSS] Release Managers for future ACS releases - enhacement
Date Thu, 26 Sep 2013 21:58:59 GMT


> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Thursday, September 26, 2013 10:22 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Release Managers for future ACS releases -
> enhacement
> 
> Agreed.  If you look at what a release manager has to do today
> 
> - triage bugs
> - follow up on reviews and ask people to commit them
> - cherry-pick fixes
> 
> To me it is a lot of work for one person to do for CloudStack.  We can
> certainly divide up the work.  For example,
> 
>  - One RM is responsible for overall release
>  - One RM is responsible for following up on review board
>  - Two or three RMs is responsible for triaging bugs
>  - One is responsible for cherry-pick
> 
> I also like to propose that we stop the practice of only assigning bugs
> to yourself.  I know it's there to make sure there's no cookie-licking
> but really let's not make ourselves less efficient just for the sake of
> appearances.   RMs should be able to assign bugs as part of the process
> to ask for someone to look at the bug rather than having to ask
> privately and have the person assign to themselves.  Keeping track of
> such things with the amount of changes CloudStack goes through in a
> release just makes us less efficient and less enjoyable to work on
> CloudStack.
> 
> --Alex
[Animesh>] Alex thanks for bringing this up I was going to reopen the "Do not assign tickets
to people" thread after 4.2 is announced. To set the perspective 4.2 was a huge release whereas
community  fixed 1900+ issues in 7 months. That speaks a lot about the vibrancy of our community
but as a release manager not being able to assign the bugs was a huge hindrance.  I had to
export all the data out every day in excel run pivots and follow through in private emails
and keep an inventory on which one did not get responded to in offline spreadsheets. It is
so much easier to use JIRA and keep the whole context in one place and also it makes all the
effort towards shipping a release  transparent and public.

If you look in JIRA we have over 250 unassigned issues that were create over 6 months ago
and over 700 open unassigned issues, without active triage and the ability to assign our backlog
will continue to grow.


Thanks
Animesh


> 
> > -----Original Message-----
> > From: Musayev, Ilya [mailto:imusayev@webmd.net]
> > Sent: Thursday, September 26, 2013 9:02 AM
> > To: dev@cloudstack.apache.org
> > Subject: [DISCUSS] Release Managers for future ACS releases -
> > enhacement
> >
> > I apologize in advance if this is a repeat of something that was
> > previously stated.
> >
> > As Animesh learned recently with ACS 4.2, RM work for major versions
> > takes a lot of effort, to lesser extent the 4.2.x minor release may
> > not be as involved, but still decent amount of work.
> >
> > What complicates the matter further, is many of us have $dayjobs$ that
> > don't emphasize heavy involvement on ACS.
> >
> > Perhaps we can revisit the strategy and have 2 -3 release managers for
> > major version and 1-2 for minor.
> >
> > Obviously, one is going the be a Lead RM, and others will be secondary
> > but also involved.
> >
> > Any thoughts on this approach?
> >
> > Thanks
> > ilya


Mime
View raw message