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.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
