Thanks for the summary Somesh and thanks for Mike for the clarification. (3) sounds good - it's always good to let everyone know that you've/reporter created a blocker bug! Hope we will have enough people to chime in to voice their yea's or nay's?
-----Original Message----- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, August 11, 2015 6:02 AM To: dev@cloudstack.apache.org Subject: Re: Revisit Process for creating Blocker bugs "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=30746 > 287 > > 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>*™*
