cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raja Pullela <>
Subject Re: Revisit Process for creating Blocker bugs
Date Sat, 01 Aug 2015 02:37:11 GMT
Irrespective of what ever defect an user creates, people involved can always comment on a bug
a downgrade the defect (like Somesh said, RM can do this).  This is a standard process we
have used earlier.  

My 2 years with this project, I don't remember there was a time when few folks have created
a bunch of blockers with a malicious intent of blocking a release?  We should approach to
this as people create defects with a "good" intent.

IMHO, creating a process to NOT to see showstopper issues (making a discussion) for a product
is putting on blinders for quality!  Example being,  to few issues that were raised this week,
we are still waiting for people chime in with their feedback.  If no one gets back, we will
be putting out a product that has a bunch of showstopper issues.  

I hope everyone has seen the automation wiki details that was posted yesterday - which should
be concern for putting out a quality product!

> On Aug 1, 2015, at 3:22 AM, Daan Hoogland <> wrote:
> Somesh, please see my replies in line;
>> On Fri, Jul 31, 2015 at 10:31 PM, Somesh Naidu <> 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 []
>> 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 <>
>>> +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 []
>>> 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

View raw message