kewl, Are you sure btw, the openoffice page does state that blockers first have to be discussed on the mailing list, which was I think the argument to start this thread.
On Mon, Aug 3, 2015 at 8:20 PM, Somesh Naidu <somesh.na...@citrix.com> wrote: > Daan, that sounds perfect to me! > > Regards, > Somesh > > > -----Original Message----- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: Monday, August 03, 2015 4:59 AM > To: dev > Subject: Re: Revisit Process for creating Blocker bugs > > Raja, Somesh, > > I want to revise my stand on this slightly; If we make a page like the > openoffice on Somesh shared which states in a little less abstract > ways clear categories that define a blocker we can quicken our > discussions on the subject. An RM could then quickly get feedback and > close or lower blockers that were not according to those standards. > The RM does, in those cases not have to be well informed on every > aspect of ACS. > > the list from the OO page, > <l> > it is a regression in main functionality > it is a crash in main functionality > it is a freeze or loop in main functionality > it is a security issue > it is a privacy issue > it is a data loss > it is a build breaker on one or more of the generally supported platforms > it is an important usability issue in Accessibility (A11Y) > it is a legal issue > it is a translation merge issue > </l> > , is on some points to vague to me to be usable. Also I would want to > be more restrictive. We can not deal with blockers on components if no > active community member use them, so the component/functionality part > should include a strict definition. Also the main part should be well > defined. > > The strictness I propose is only for accepting without discussion that > an issue is a blocker. So anyone, RM, reporter or others can of course > always start a discussion that any more or less trivial issue be > regarded as blocker anyway. > > i want to have one remark on the page on blockers if we create it: > "Please keep in mind that stopping a release, for what is a blocker to > one user may block another user that is in dire need for added > functionality and not blocked by the new issue." > > sound reasonable? > > On Sat, Aug 1, 2015 at 9:36 AM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > > Thanks Somesh, It is a usefull link. > > > > Now if for instance an installation can not be used because no initial > > zane can be created, this would be a showstopper. But if a release > > does not have certain obscure features (even as regression) we have a > > discussion. Not whether we should fix it. I am totally with you on > > that. It does not block a release and does not render a deployment of > > such a release completely useless. It will be useless for a group of > > users while it may at the same time remove blockers from previous > > releases for other groups of users. > > > > This dilemma I want to address by introducing the difference. I have > > not seen much 'blocker's amongst the blockers that where reported in > > cloudstack. There were some, sure but most were regressions that would > > hinder some users and as we could well decide that these are blockers > > (and I think we should in *most* cases). they block users and not > > necessarily a release. > > > > > > > > > > On Sat, Aug 1, 2015 at 12:32 AM, Somesh Naidu <somesh.na...@citrix.com> > wrote: > >> 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.hoogl...@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.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 > > > > > > > > -- > > Daan > > > > -- > Daan > -- Daan
