cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musayev, Ilya" <imusa...@webmd.net>
Subject RE: [DISCUSS] Release Managers for future ACS releases - enhacement
Date Wed, 02 Oct 2013 21:54:14 GMT
And we need to  hash out the JIRA ticket assignments and component breakdown - so it's going
to be 2 threads.

> -----Original Message-----
> From: Musayev, Ilya [mailto:imusayev@webmd.net]
> Sent: Wednesday, October 02, 2013 5:50 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Release Managers for future ACS releases -
> enhacement
> 
> Thank you all for responding.
> 
> So I guess, to move forward, I will kick off another thread asking for
> volunteers to join this effort. We then review @ PMC and finalize.
> 
> Does it sound like plan?
> 
> 
> > -----Original Message-----
> > From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> > Sent: Wednesday, October 02, 2013 5:47 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Release Managers for future ACS releases -
> > enhacement
> >
> > On 9/26/13 2:58 PM, "Animesh Chaturvedi"
> > <animesh.chaturvedi@citrix.com>
> > wrote:
> >
> > >
> > >
> > >> -----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.
> >
> >
> > +1 on the bug assignement proposal from Alex as it would save a lot of
> > time for me as a developer. At the moment I have to trace list of
> > Unassigned bugs multiple times a day, look at the logs/code in order
> > to find out whether this bug in my area or not, how critical the bug
> > is, how urgent is the fix, and whether I have time to fix it. And I
> > assume thats what the rest of the developers do. So I see the
> > following issues with the current process in addition to what Alex/Animesh
> already said:
> >
> > #1 Multiple people parsing the same big set of data, is not efficient
> > when close to release deadline. Especially when this parsing doesn't
> > result in the bug assignment/update.
> > #2 If the bug is not a blocker/critical bug, it can be left out
> > unassigned forever.
> >
> > To help the RM to make the decision on the bug assignment, the person
> > who filed the bug (if developer), or developer who did the debugging
> > for the bug but by some reason can't fix it himself, should include
> > git commit id that most likely caused the problem, to the Jira ticket.
> >
> >
> > And I'm not sayting that I want to stop checking the list of
> > unassigned bugs on a regular basis; we must do it anyway. I just want
> > this list to become shorter. And if somebody directly assigns the bug
> > to me knowing that its caused by my git commit or happening in the
> > code area I'm familiar with, I would appreciate that too.
> >
> > -Alena.
> >
> >
> >
> >
> >
> >
> > >
> > >
> > >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