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 > >
