> 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
