cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <>
Subject Re: Revisit Process for creating Blocker bugs
Date Mon, 10 Aug 2015 08:23:29 GMT

> On Aug 6, 2015, at 7:35 AM, Raja Pullela <> 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 -

> 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 [] 
> Sent: Wednesday, August 5, 2015 2:19 PM
> To: dev <>
> 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 <> 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 <> 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 
>>> <> 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 []
>>>> Sent: Tuesday, August 4, 2015 4:57 PM
>>>> To: dev <>
>>>> 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 <
>>> 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 []
>>>>> Sent: Tuesday, August 4, 2015 1:54 AM
>>>>> To: dev <>
>>>>> Subject: Re: Revisit Process for creating Blocker bugs
>>>>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu 
>>>>> <>
>>>>> 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

View raw message