Somesh, please see my replies in line; On Fri, Jul 31, 2015 at 10:31 PM, Somesh Naidu <somesh.na...@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.hoogl...@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.na...@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.pull...@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
