I think one way is, we can just enable the default assigner(maintainer) for components in Jira. The components can be break down into further smaller parts, to make sure one guy's work is not big. And the maintainer for the different components can communicate(just like RM did) to assign the bug(or resolve by themselves). I think it would be much more efficiency. CloudStack is so big now that depends on one or two person to triage the bugs is too much work for them.
One practical issue is, probably too many peoples just set component to "Management Server", then that guy would have too much work to do(mostly triage and update the component I believe). But it would be still much better than all bugs goes to one or two person to triage. --Sheng On Thu, Sep 26, 2013 at 4:06 PM, Musayev, Ilya <imusa...@webmd.net> wrote: > I can feel your pain, as well as Chip's, Dave's, Joe's and whoever was > involved in past. > > Here is a bit of uncharted territory we need to address about bug > assignment. > > In past I've seen folks ask - we have X number of bugs that need to be > triaged, who can take what? Are we still keeping this framework and do we > default to whoever wrote the code/patch initially - if no one volunteers? > > While Citrix is one of the main supporters of CloudStack project and has > people employed to do development, how does one - who has no insight into > Citrix - assign bugs to people who are employed by Citrix (and can we even > do that without their full consent)? > > One other part, since Citrix and other companies have QA teams, perhaps we > can have a closer collaboration as to what testing was done on Citrix side > when it comes to major releases? (i.e. ACS 4.2 release) > > I know in past Citrix would branch of from ACS or even have a separate > codebase, but with future releases, its all going to be one ACS code base. > So future actual release testing/qa (not automated as part of built > process) should get easier since we have folks dedicated to work on ACS > project to do QA or is this an incorrect assumption? > > I am also under impression it would help to have at least one person from > Citrix on RM team, helps with communication, as they can tap people by > other means other than mailing lists. > > There are a lot of assumptions here, I could be wrong on all or some of > these, please clarify or voice your opinion. > > Thanks > ilya > > > > > > > -----Original Message----- > > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > > Sent: Thursday, September 26, 2013 5:25 PM > > To: dev@cloudstack.apache.org > > Subject: RE: [DISCUSS] Release Managers for future ACS releases - > > enhacement > > > > +1 > > > > Ilya I am glad that you brought it up and recognize the challenge. I > survived > > on 3 cups of JetFuel[1] every day for last 3 months. It's like doing two > > $dayjob$ shifts > > > > http://www.keurig.com/coffee/jet-fuel-extra-bold-coffee-k-cup-coffee- > > people > > > > > > > > > -----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 > > > > >
