cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raja Pullela <raja.pull...@citrix.com>
Subject RE: Revisit Process for creating Blocker bugs
Date Thu, 06 Aug 2015 05:35:56 GMT
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.

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