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.prokharc...@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.chaturv...@citrix.com> > wrote: > > > > > > >> -----Original Message----- > >> From: Alex Huang [mailto:alex.hu...@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:imusa...@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 > > > > > >
