cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Somesh Naidu <Somesh.Na...@citrix.com>
Subject RE: Revisit Process for creating Blocker bugs
Date Fri, 31 Jul 2015 22:32:05 GMT
Daan,

I was using the term "blocker" in context of a release and hence suggesting involvement of
RM in getting a closure.

In terms of defect categorization, I found this both relevant and helpful - https://wiki.openoffice.org/wiki/Showstopper.

Regards,
Somesh


-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
Sent: Friday, July 31, 2015 5:52 PM
To: dev
Subject: Re: Revisit Process for creating Blocker bugs

Somesh, please see my replies in line;

On Fri, Jul 31, 2015 at 10:31 PM, Somesh Naidu <Somesh.Naidu@citrix.com> wrote:
> Daan,
>
> While I have the same opinion as you that "No one should be able to block a release on
their own". I also agree that the issue should be posted to the ML for discussion and it is
the responsibility of the person who posted the defect to do so.
>
> I am more concerned with the process. My concern is specifically around this comment
from Raja "If no one supports the defect/issue, we will be putting out a release that has
showstopper issues."
>
> I mean for one, there should be a way for someone to flag an issue as blocker/showstopper
and two, ensure that there is an explicit decision being made on the severity.

ad one: you can send a mail saying "in my opinion the issue
CLOUDSTACK-### should be considdered a blocker"
ad two: we have such a process, we vote by lazy consensus on technical
issues on dev@

>
> To me it makes more sense to do this the other way round, that is, the person who found
the issue raises the issue based on his understanding of the severity/impact. The person who
is responsible for triaging (which in this case is the community) shall use their discretion
to justify the severity and if it doesn't substantiate then downgrade/upgrade the same.

this leaves teh community open to being taken hostage by a single
person or a small group that keeps bombarding us with blockers. I am
being paranoia by past experience.

>
> Isn't this the general engineering practice?

Not to my knowledge, not in this case. Of course we can have a
discussion about the semantics of 'blocker'. And then a user may be
blocked but that is not this case: our release should be blocked is
what blocker means to us. For all practical purposes we don't have a
severity 'blocks user'.

>
> In addition, we'd have a guidelines on defect categorization for reference that can be
looked up while raising a defect.

that is a very good idea.

>
> Regards,
> Somesh
>
>
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Friday, July 31, 2015 2:34 PM
> To: dev
> Subject: Re: Revisit Process for creating Blocker bugs
>
> -1 blocker means blocker and blocks a release. No one should be able
> to block a release on their own. We should treat the critical category
> as a staging area for those issues.
>
> On Fri, Jul 31, 2015 at 5:51 PM, Somesh Naidu <Somesh.Naidu@citrix.com> wrote:
>> +1
>>
>> Categorizing an issue as blocker/showstopper should need some kind of moderation.
One possibility, voting and/or require approval from certain # of PMCs. Alternately, this
could also be left to the discretion of the RM.
>>
>> Regards,
>> Somesh
>>
>> -----Original Message-----
>> From: Raja Pullela [mailto:raja.pullela@citrix.com]
>> Sent: Friday, July 31, 2015 11:15 AM
>> To: CloudStack Dev
>> Subject: Revisit Process for creating Blocker bugs
>>
>> Hi,
>>
>> I am requesting to see if we can revisit the process for creating "blocker" defects.
 I heard and do understand that someone can create a blocker defect and may not actively involve
in closing it out and it doesn't help the product.  I am not clear if we are doing this at
and around RC time - however it doesn't matter.
>>
>> IMHO, feel that someone's involvement should not be taken as a reason for incorrectly
categorizing a defect, meaning a blocker defect being created as a Critical and opening up
a discussion to review.  If no one supports the defect/issue, we will be putting out a release
that has showstopper issues.
>>
>> Please share your thoughts and concerns for or against lifting this restriction!
>>
>> Raja
>
>
>
> --
> Daan



-- 
Daan
Mime
View raw message