cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Somesh Naidu <Somesh.Na...@citrix.com>
Subject RE: Revisit Process for creating Blocker bugs
Date Mon, 10 Aug 2015 16:24:13 GMT
> 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:runseb@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.pullela@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.hoogland@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.das@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.hoogland@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.katru@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.hoogland@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.katru@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.hoogland@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.Naidu@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

Mime
View raw message