cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: [DISCUSS] Release Managers for future ACS releases - enhacement
Date Wed, 02 Oct 2013 21:47:03 GMT
On 9/26/13 2:58 PM, "Animesh Chaturvedi" <>

>> -----Original Message-----
>> From: Alex Huang []
>> Sent: Thursday, September 26, 2013 10:22 AM
>> To:
>> 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

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.


>> > -----Original Message-----
>> > From: Musayev, Ilya []
>> > Sent: Thursday, September 26, 2013 9:02 AM
>> > To:
>> > 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

View raw message