You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Alena Prokharchyk <Al...@citrix.com> on 2013/10/02 23:47:03 UTC
Re: [DISCUSS] Release Managers for future ACS releases - enhacement
On 9/26/13 2:58 PM, "Animesh Chaturvedi" <an...@citrix.com>
wrote:
>
>
>> -----Original Message-----
>> From: Alex Huang [mailto:Alex.Huang@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:imusayev@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
>
>
RE: [DISCUSS] Release Managers for future ACS releases - enhacement
Posted by "Musayev, Ilya" <im...@webmd.net>.
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:imusayev@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.Prokharchyk@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"
> > <an...@citrix.com>
> > wrote:
> >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Alex Huang [mailto:Alex.Huang@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:imusayev@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
> > >
> > >
> >
> >
>
>
RE: [DISCUSS] Release Managers for future ACS releases - enhacement
Posted by "Musayev, Ilya" <im...@webmd.net>.
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.Prokharchyk@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"
> <an...@citrix.com>
> wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: Alex Huang [mailto:Alex.Huang@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:imusayev@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
> >
> >
>
>