> -----Original Message----- > From: Alex Huang [mailto:alex.hu...@citrix.com] > Sent: 26 September 2013 22:52 > 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
[RamG] The last point above can be simplified by having the committer(owner of the commit) to commit into the respective branch(es) once he\she gets a "OK to commit" email response from the release manager. And Yes looking at the feature velocity and code churn we need more than one release manager and a better processes in place. > > 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 > > > -----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
