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:imusa...@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.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 > > > > > > > > > > > >
