"3. In case the reporter feels the defect qualifies as a Blocker, they should raise it as Blocker and create a discussion/voting thread on the ML for the same."
This is what I always do these days and I think it makes a lot of sense: Go ahead and mark the bug as a Blocker, but then send out an obvious e-mail (i.e. well-named Subject) to the list to begin discussion around it. On Mon, Aug 10, 2015 at 10:24 AM, Somesh Naidu <somesh.na...@citrix.com> wrote: > > I did not see (or understand) a major change proposed or needed in this > thread. > > The primary topic of discussion is categorization of a defect as Blocker, > that is, how to qualify a defect as Blocker. The discussion scope widened > and included process to raise an issue as "Blocker". > > The issue/discussion seems to have risen due to some folks (Raja and team) > raising a blocker without discussion on ML. As a counter measure, these > defects were downgraded to "Critical" (by Daan). > > In terms of qualification for a blocker, the two school of thoughts were, > Raja/Ram - consideration should be drawn from the technical/functional > impact irrespective of how many users are affected. > Daan - consideration should be drawn from how many users are affected > (achieved by voting). > > In terms of the process, two approaches proposed were, > Raja/Ram - the reporter should first set the priority level to "Blocker" > and in parallel raise it for discussion on the ML. > Daan - the reporter should raise such defect as "Critical" and then work > on promoting it to "Blocker" via lazy consensus. > > I am not entirely sure which approach suggests a change. > > @Daan/Raja - My sincere apologies in case my summary has inaccuracies; > please feel free to correct. > > My proposal was (matches with mostly what Sebastian said), > 1. Create a wiki page with more detailed guidelines and processes for > Release Blockers. > 2. The reporter should raise a defect by qualifying against the above > guidelines. > 3. In case the reporter feels the defect qualifies as a Blocker, they > should raise it as Blocker and create a discussion/voting thread on the ML > for the same. > 4. RM should ensure an explicit decision is made on the severity and > upgrade/downgrade accordingly. Note, RM having the responsibility and > authority to drive closure does not equate to veto power. > > Regards, > Somesh > > > -----Original Message----- > From: Sebastien Goasguen [mailto:run...@gmail.com] > Sent: Monday, August 10, 2015 4:23 AM > To: dev@cloudstack.apache.org > Subject: Re: Revisit Process for creating Blocker bugs > > > > On Aug 6, 2015, at 7:35 AM, Raja Pullela <raja.pull...@citrix.com> > wrote: > > > > Looks like there are few of us who differ with the current > process/restriction. > > Just to close this thread - there are already guidelines that exist > currently and we should continue to adopt or follow those. Let the > Release Manager or other people closely involved with a particular release > decide on whether a particular bug is correctly categorized or not. They > should have the veto power to downgrade or upgrade, as necessary. > > > > I would not call it veto power. > > Folks will file tickets and put a priority level, a RM will see blockers > and when those are not resolved, the RM should go on the list and get a > feel from the community about those blockers (whether they are or not). > > I did not see (or understand) a major change proposed or needed in this > thread. > > > > Assess Priority - > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30746287 > > When creating a new Jira ticket, please take a minute to correctly > assess the priority of the issue. By default, Jira assigns a new issue a > Priority level of Major. In many cases, this is wrong. Please be sure to > set the Priority correctly: > > Blocker: Blocks development and/or testing work, production cannot run. > Security issues. > > Critical: Crashes, loss of data, severe memory leak. > > Major: Major loss of function, broken feature, returns incorrect > information, etc. > > Minor: Minor loss of function, problem with an easy workaround. Wishlist > items. > > Trivial: Typos that don't affect comprehension of the UI, misaligned > text, etc. > > > > -----Original Message----- > > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > > Sent: Wednesday, August 5, 2015 2:19 PM > > To: dev <dev@cloudstack.apache.org> > > Subject: Re: Revisit Process for creating Blocker bugs > > > > Koushik, that would be true if we had our upgrade process in order. > > > > On Wed, Aug 5, 2015 at 7:14 AM, Koushik Das <koushik....@citrix.com> > wrote: > > > >> If there is a group of users in dire need for a specific feature they > >> can always take the code and use it. No need to wait for an official > release. > >> Official release should adhere to quality guidelines (at least in > >> terms of any reported regressions) even if it means release getting > delayed. > >> > >> > >> On 05-Aug-2015, at 2:39 AM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > >> > >>> Yes we can if there is a group of users that don't use it but are in > >>> dire need far another feature. We just have to document and market > >>> it properly > >>> > >>> On Tue, Aug 4, 2015 at 6:48 PM, Ramanath Katru > >>> <ramanath.ka...@citrix.com> wrote: > >>>> Daan, > >>>> > >>>> I beg to differ. This is very much a product issue. We cannot > >>>> knowingly > >> release with an existing/working functionality broken. Especially if > >> it is one of the features that users expect to be there. Remote Access > >> VPN is an example. Right now this functionality is broken. > >>>> > >>>> Ram Katru > >>>> > >>>> -----Original Message----- > >>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > >>>> Sent: Tuesday, August 4, 2015 4:57 PM > >>>> To: dev <dev@cloudstack.apache.org> > >>>> Subject: Re: Revisit Process for creating Blocker bugs > >>>> > >>>> Ram, > >>>> > >>>> This is a marketing issue, not a release issue. making a release or > >> marketing it to the general public are two different things. > >>>> > >>>> Daan > >>>> > >>>> On Tue, Aug 4, 2015 at 12:41 PM, Ramanath Katru < > >> ramanath.ka...@citrix.com> wrote: > >>>>> While we can say if a bug doesn’t effect "majority" of current > >>>>> users, > >> we can go ahead and release, but we should also look at a product > >> perspective not just release perspective. There are some features that > >> are important for cloudstack as a product and these cannot be broken > >> in a release. If we do not evaluate from a product perspective, then > >> we will be turning potential new users away. > >>>>> > >>>>> Ram Katru > >>>>> > >>>>> -----Original Message----- > >>>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > >>>>> Sent: Tuesday, August 4, 2015 1:54 AM > >>>>> To: dev <dev@cloudstack.apache.org> > >>>>> Subject: Re: Revisit Process for creating Blocker bugs > >>>>> > >>>>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu > >>>>> <somesh.na...@citrix.com> > >>>>> wrote: > >>>>> > >>>>>> I would like to add that while the # of users affected is > >>>>>> definitely a major factor when ascertaining severity of an issue, > >>>>>> should we not consider the technical scope and/or use-case of a > >>>>>> defect. For example, let's say there is only one user using basic > >>>>>> zone setup with VMware in the community but the bug/regression > >>>>>> has caused a major failure like "No provisioning of VMs". Would > >>>>>> this be considered a > >> release blocker? > >>>>>> > >>>>> > >>>>> This is exactly the kind of discussion we need to have when such a > >> case comes by. For this as purely hypothetical case I would say, > release. > >> We can not have other users abstain from badly needed features because > >> one can not share in the joy. We would have to release a fix for this > >> afterwards. > >>>>> > >>>>> just a 0.02 in virtual currency > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Daan > >>>> > >>>> > >>>> > >>>> -- > >>>> Daan > >>> > >>> > >>> > >>> -- > >>> Daan > >> > >> > > > > > > -- > > Daan > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
