Revisit Process for creating Blocker bugs

[Raja Pullela <ra...@citrix.com>]

Hi,

I am requesting to see if we can revisit the process for creating "blocker" defects.  I heard and do understand that someone can create a blocker defect and may not actively involve in closing it out and it doesn't help the product.  I am not clear if we are doing this at and around RC time - however it doesn't matter.

IMHO, feel that someone's involvement should not be taken as a reason for incorrectly categorizing a defect, meaning a blocker defect being created as a Critical and opening up a discussion to review.  If no one supports the defect/issue, we will be putting out a release that has showstopper issues.  

Please share your thoughts and concerns for or against lifting this restriction!

Raja 

Re: Revisit Process for creating Blocker bugs

[Daan Hoogland <da...@gmail.com>]

On Sat, Aug 1, 2015 at 4:37 AM, Raja Pullela <ra...@citrix.com> wrote:
> My 2 years with this project, I don't remember there was a time when few folks have created a bunch of blockers with a malicious intent of blocking a release?  We should approach to this as people create defects with a "good" intent.

Even with good intent, or what happened before, with zealous
dedication to a job, the community can be held hostage.

>
> IMHO, creating a process to NOT to see showstopper issues (making a discussion) for a product is putting on blinders for quality!  Example being,  to few issues that were raised this week, we are still waiting for people chime in with their feedback.  If no one gets back, we will be putting out a product that has a bunch of showstopper issues.

Why? You and others (the reporters) are here to speak about it on
list, are you? The release process is far from automated. If it was I
would agree that we run this risk.

-- 
Daan

Re: Revisit Process for creating Blocker bugs

[Raja Pullela <ra...@citrix.com>]

Irrespective of what ever defect an user creates, people involved can always comment on a bug a downgrade the defect (like Somesh said, RM can do this).  This is a standard process we have used earlier.  

My 2 years with this project, I don't remember there was a time when few folks have created a bunch of blockers with a malicious intent of blocking a release?  We should approach to this as people create defects with a "good" intent.

IMHO, creating a process to NOT to see showstopper issues (making a discussion) for a product is putting on blinders for quality!  Example being,  to few issues that were raised this week, we are still waiting for people chime in with their feedback.  If no one gets back, we will be putting out a product that has a bunch of showstopper issues.  

I hope everyone has seen the automation wiki details that was posted yesterday - which should be concern for putting out a quality product!

> On Aug 1, 2015, at 3:22 AM, Daan Hoogland <da...@gmail.com> wrote:
> 
> Somesh, please see my replies in line;
> 
>> On Fri, Jul 31, 2015 at 10:31 PM, Somesh Naidu <So...@citrix.com> wrote:
>> Daan,
>> 
>> While I have the same opinion as you that "No one should be able to block a release on their own". I also agree that the issue should be posted to the ML for discussion and it is the responsibility of the person who posted the defect to do so.
>> 
>> I am more concerned with the process. My concern is specifically around this comment from Raja "If no one supports the defect/issue, we will be putting out a release that has showstopper issues."
>> 
>> I mean for one, there should be a way for someone to flag an issue as blocker/showstopper and two, ensure that there is an explicit decision being made on the severity.
> 
> ad one: you can send a mail saying "in my opinion the issue
> CLOUDSTACK-### should be considdered a blocker"
> ad two: we have such a process, we vote by lazy consensus on technical
> issues on dev@
> 
>> 
>> To me it makes more sense to do this the other way round, that is, the person who found the issue raises the issue based on his understanding of the severity/impact. The person who is responsible for triaging (which in this case is the community) shall use their discretion to justify the severity and if it doesn't substantiate then downgrade/upgrade the same.
> 
> this leaves teh community open to being taken hostage by a single
> person or a small group that keeps bombarding us with blockers. I am
> being paranoia by past experience.
> 
>> 
>> Isn't this the general engineering practice?
> 
> Not to my knowledge, not in this case. Of course we can have a
> discussion about the semantics of 'blocker'. And then a user may be
> blocked but that is not this case: our release should be blocked is
> what blocker means to us. For all practical purposes we don't have a
> severity 'blocks user'.
> 
>> 
>> In addition, we'd have a guidelines on defect categorization for reference that can be looked up while raising a defect.
> 
> that is a very good idea.
> 
>> 
>> Regards,
>> Somesh
>> 
>> 
>> -----Original Message-----
>> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
>> Sent: Friday, July 31, 2015 2:34 PM
>> To: dev
>> Subject: Re: Revisit Process for creating Blocker bugs
>> 
>> -1 blocker means blocker and blocks a release. No one should be able
>> to block a release on their own. We should treat the critical category
>> as a staging area for those issues.
>> 
>>> On Fri, Jul 31, 2015 at 5:51 PM, Somesh Naidu <So...@citrix.com> wrote:
>>> +1
>>> 
>>> Categorizing an issue as blocker/showstopper should need some kind of moderation. One possibility, voting and/or require approval from certain # of PMCs. Alternately, this could also be left to the discretion of the RM.
>>> 
>>> Regards,
>>> Somesh
>>> 
>>> -----Original Message-----
>>> From: Raja Pullela [mailto:raja.pullela@citrix.com]
>>> Sent: Friday, July 31, 2015 11:15 AM
>>> To: CloudStack Dev
>>> Subject: Revisit Process for creating Blocker bugs
>>> 
>>> Hi,
>>> 
>>> I am requesting to see if we can revisit the process for creating "blocker" defects.  I heard and do understand that someone can create a blocker defect and may not actively involve in closing it out and it doesn't help the product.  I am not clear if we are doing this at and around RC time - however it doesn't matter.
>>> 
>>> IMHO, feel that someone's involvement should not be taken as a reason for incorrectly categorizing a defect, meaning a blocker defect being created as a Critical and opening up a discussion to review.  If no one supports the defect/issue, we will be putting out a release that has showstopper issues.
>>> 
>>> Please share your thoughts and concerns for or against lifting this restriction!
>>> 
>>> Raja
>> 
>> 
>> 
>> --
>> Daan
> 
> 
> 
> -- 
> Daan

RE: Revisit Process for creating Blocker bugs

[Raja Pullela <ra...@citrix.com>]

Thanks for the summary Somesh and thanks for Mike for the clarification.  
(3) sounds good - it's always good to let everyone know that you've/reporter created a blocker bug!   Hope we will have enough people to chime in to voice their yea's or nay's?

-----Original Message-----
From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com] 
Sent: Tuesday, August 11, 2015 6:02 AM
To: dev@cloudstack.apache.org
Subject: Re: Revisit Process for creating Blocker bugs

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

This is what I always do these days and I think it makes a lot of sense: Go ahead and mark the bug as a Blocker, but then send out an obvious e-mail (i.e. well-named Subject) to the list to begin discussion around it.

On Mon, Aug 10, 2015 at 10:24 AM, Somesh Naidu <So...@citrix.com>
wrote:

> > 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 <ra...@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=30746
> 287
> > 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 <de...@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 <ko...@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 <da...@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 
> >>> <ra...@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 <de...@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 <de...@cloudstack.apache.org>
> >>>>> Subject: Re: Revisit Process for creating Blocker bugs
> >>>>>
> >>>>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu 
> >>>>> <So...@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
>
>


--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Re: Revisit Process for creating Blocker bugs

[Mike Tutkowski <mi...@solidfire.com>]

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

This is what I always do these days and I think it makes a lot of sense: Go
ahead and mark the bug as a Blocker, but then send out an obvious e-mail
(i.e. well-named Subject) to the list to begin discussion around it.

On Mon, Aug 10, 2015 at 10:24 AM, Somesh Naidu <So...@citrix.com>
wrote:

> > 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 <ra...@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 <de...@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 <ko...@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 <da...@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
> >>> <ra...@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 <de...@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 <de...@cloudstack.apache.org>
> >>>>> Subject: Re: Revisit Process for creating Blocker bugs
> >>>>>
> >>>>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu
> >>>>> <So...@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
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

RE: Revisit Process for creating Blocker bugs

[Somesh Naidu <So...@citrix.com>]

> 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 <ra...@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 <de...@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 <ko...@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 <da...@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 
>>> <ra...@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 <de...@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 <de...@cloudstack.apache.org>
>>>>> Subject: Re: Revisit Process for creating Blocker bugs
>>>>> 
>>>>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu 
>>>>> <So...@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

Re: Revisit Process for creating Blocker bugs

[Sebastien Goasguen <ru...@gmail.com>]

> On Aug 6, 2015, at 7:35 AM, Raja Pullela <ra...@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 <de...@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 <ko...@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 <da...@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 
>>> <ra...@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 <de...@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 <de...@cloudstack.apache.org>
>>>>> Subject: Re: Revisit Process for creating Blocker bugs
>>>>> 
>>>>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu 
>>>>> <So...@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

RE: Revisit Process for creating Blocker bugs

[Raja Pullela <ra...@citrix.com>]

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 <de...@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 <ko...@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 <da...@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 
> > <ra...@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 <de...@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 <de...@cloudstack.apache.org>
> >>> Subject: Re: Revisit Process for creating Blocker bugs
> >>>
> >>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu 
> >>> <So...@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

Re: Revisit Process for creating Blocker bugs

[Daan Hoogland <da...@gmail.com>]

Koushik, that would be true if we had our upgrade process in order.

On Wed, Aug 5, 2015 at 7:14 AM, Koushik Das <ko...@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 <da...@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
> > <ra...@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 <de...@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 <de...@cloudstack.apache.org>
> >>> Subject: Re: Revisit Process for creating Blocker bugs
> >>>
> >>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu
> >>> <So...@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

Re: Revisit Process for creating Blocker bugs

[Koushik Das <ko...@citrix.com>]

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 <da...@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
> <ra...@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 <de...@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 <ra...@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 <de...@cloudstack.apache.org>
>>> Subject: Re: Revisit Process for creating Blocker bugs
>>> 
>>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu
>>> <So...@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

RE: Revisit Process for creating Blocker bugs

[Suresh Sadhu <Su...@citrix.com>]

+1 I agree with Ram.

-----Original Message-----
From: Ramanath Katru [mailto:ramanath.katru@citrix.com] 
Sent: Wednesday, August 5, 2015 9:41 AM
To: dev@cloudstack.apache.org
Subject: RE: Revisit Process for creating Blocker bugs

Wow. I think we need a consensus here. When a feature needs to be added, we go through proposals and a healthy discussion on whether the feature can be added or not. We need to do the same if an important feature support is to be removed. It cannot be a call to be made at the time of release and for the sake of making a release. We cannot pull the rug from underneath users. This is good way of losing confidence in a product open source or not.

Ram Katru

-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
Sent: Wednesday, August 5, 2015 2:40 AM
To: dev <de...@cloudstack.apache.org>
Subject: Re: Revisit Process for creating Blocker bugs

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 <ra...@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 <de...@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 <ra...@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 <de...@cloudstack.apache.org>
>> Subject: Re: Revisit Process for creating Blocker bugs
>>
>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu 
>> <So...@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

RE: Revisit Process for creating Blocker bugs

[Ramanath Katru <ra...@citrix.com>]

Wow. I think we need a consensus here. When a feature needs to be added, we go through proposals and a healthy discussion on whether the feature can be added or not. We need to do the same if an important feature support is to be removed. It cannot be a call to be made at the time of release and for the sake of making a release. We cannot pull the rug from underneath users. This is good way of losing confidence in a product open source or not.

Ram Katru

-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
Sent: Wednesday, August 5, 2015 2:40 AM
To: dev <de...@cloudstack.apache.org>
Subject: Re: Revisit Process for creating Blocker bugs

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 <ra...@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 <de...@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 <ra...@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 <de...@cloudstack.apache.org>
>> Subject: Re: Revisit Process for creating Blocker bugs
>>
>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu 
>> <So...@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

Re: Revisit Process for creating Blocker bugs

[Daan Hoogland <da...@gmail.com>]

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
<ra...@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 <de...@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 <ra...@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 <de...@cloudstack.apache.org>
>> Subject: Re: Revisit Process for creating Blocker bugs
>>
>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu
>> <So...@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

Re: Revisit Process for creating Blocker bugs

[Sebastien Goasguen <ru...@gmail.com>]

> On Aug 4, 2015, at 6:48 PM, Ramanath Katru <ra...@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.
> 

Then as contributor to cloudstack, put this ticket as a blocker (if you feel it needs to be a blocker).

Then the RM will have to deal with it and a discussion might follow on the list to solve this particular issue.



> Ram Katru
> 
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
> Sent: Tuesday, August 4, 2015 4:57 PM
> To: dev <de...@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 <ra...@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 <de...@cloudstack.apache.org>
>> Subject: Re: Revisit Process for creating Blocker bugs
>> 
>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu 
>> <So...@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

RE: Revisit Process for creating Blocker bugs

[Ramanath Katru <ra...@citrix.com>]

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 <de...@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 <ra...@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 <de...@cloudstack.apache.org>
> Subject: Re: Revisit Process for creating Blocker bugs
>
> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu 
> <So...@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

Re: Revisit Process for creating Blocker bugs

[Daan Hoogland <da...@gmail.com>]

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
<ra...@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 <de...@cloudstack.apache.org>
> Subject: Re: Revisit Process for creating Blocker bugs
>
> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu <So...@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

RE: Revisit Process for creating Blocker bugs

[Ramanath Katru <ra...@citrix.com>]

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 <de...@cloudstack.apache.org>
Subject: Re: Revisit Process for creating Blocker bugs

On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu <So...@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

Re: Revisit Process for creating Blocker bugs

[Daan Hoogland <da...@gmail.com>]

On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu <So...@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

RE: Revisit Process for creating Blocker bugs

[Somesh Naidu <So...@citrix.com>]

Daan,

Yes, I am. Don't know about others but I was never against discussion on ML. I know there cannot be a process in Apache community that does not involve discussion on ML.

I was primarily concerned with the fact that there is no pressure on the community to make an explicit decision. Requiring and empowering RM to make an explicit call in addition to clear guidelines for what qualifies as a blocker works for me.

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?

Regards,
Somesh


-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
Sent: Monday, August 03, 2015 2:43 PM
To: dev
Subject: Re: Revisit Process for creating Blocker bugs

kewl,

Are you sure btw, the openoffice page does state that blockers first have
to be discussed on the mailing list, which was I think the argument to
start this thread.

On Mon, Aug 3, 2015 at 8:20 PM, Somesh Naidu <So...@citrix.com>
wrote:

> Daan, that sounds perfect to me!
>
> Regards,
> Somesh
>
>
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Monday, August 03, 2015 4:59 AM
> To: dev
> Subject: Re: Revisit Process for creating Blocker bugs
>
> Raja, Somesh,
>
> I want to revise my stand on this slightly; If we make a page like the
> openoffice on Somesh shared which states in a little less abstract
> ways clear categories that define a blocker we can quicken our
> discussions on the subject. An RM could then quickly get feedback and
> close or lower blockers that were not according to those standards.
> The RM does, in those cases not have to be well informed on every
> aspect of ACS.
>
> the list from the OO page,
> <l>
> it is a regression in main functionality
> it is a crash in main functionality
> it is a freeze or loop in main functionality
> it is a security issue
> it is a privacy issue
> it is a data loss
> it is a build breaker on one or more of the generally supported platforms
> it is an important usability issue in Accessibility (A11Y)
> it is a legal issue
> it is a translation merge issue
> </l>
> , is on some points to vague to me to be usable. Also I would want to
> be more restrictive. We can not deal with blockers on components if no
> active community member use them, so the component/functionality part
> should include a strict definition. Also the main part should be well
> defined.
>
> The strictness I propose is only for accepting without discussion that
> an issue is a blocker. So anyone, RM, reporter or others can of course
> always start a discussion that any more or less trivial issue be
> regarded as blocker anyway.
>
> i want to have one remark on the page on blockers if we create it:
> "Please keep in mind that stopping a release, for what is a blocker to
> one user may block another user that is in dire need for added
> functionality and not blocked by the new issue."
>
> sound reasonable?
>
> On Sat, Aug 1, 2015 at 9:36 AM, Daan Hoogland <da...@gmail.com>
> wrote:
> > Thanks Somesh, It is a usefull link.
> >
> > Now if for instance an installation can not be used because no initial
> > zane can be created, this would be a showstopper. But if a release
> > does not have certain obscure features (even as regression) we have a
> > discussion. Not whether we should fix it. I am totally with you on
> > that. It does not block a release and does not render a deployment of
> > such a release completely useless. It will be useless for a group of
> > users while it may at the same time remove blockers from previous
> > releases for other groups of users.
> >
> > This dilemma I want to address by introducing the difference. I have
> > not seen much 'blocker's amongst the blockers that where reported in
> > cloudstack. There were some, sure but most were regressions that would
> > hinder some users and as we could well decide that these are blockers
> > (and I think we should in *most* cases). they block users and not
> > necessarily a release.
> >
> >
> >
> >
> > On Sat, Aug 1, 2015 at 12:32 AM, Somesh Naidu <So...@citrix.com>
> wrote:
> >> Daan,
> >>
> >> I was using the term "blocker" in context of a release and hence
> suggesting involvement of RM in getting a closure.
> >>
> >> In terms of defect categorization, I found this both relevant and
> helpful - https://wiki.openoffice.org/wiki/Showstopper.
> >>
> >> Regards,
> >> Somesh
> >>
> >>
> >> -----Original Message-----
> >> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> >> Sent: Friday, July 31, 2015 5:52 PM
> >> To: dev
> >> Subject: Re: Revisit Process for creating Blocker bugs
> >>
> >> Somesh, please see my replies in line;
> >>
> >> On Fri, Jul 31, 2015 at 10:31 PM, Somesh Naidu <So...@citrix.com>
> wrote:
> >>> Daan,
> >>>
> >>> While I have the same opinion as you that "No one should be able to
> block a release on their own". I also agree that the issue should be posted
> to the ML for discussion and it is the responsibility of the person who
> posted the defect to do so.
> >>>
> >>> I am more concerned with the process. My concern is specifically
> around this comment from Raja "If no one supports the defect/issue, we will
> be putting out a release that has showstopper issues."
> >>>
> >>> I mean for one, there should be a way for someone to flag an issue as
> blocker/showstopper and two, ensure that there is an explicit decision
> being made on the severity.
> >>
> >> ad one: you can send a mail saying "in my opinion the issue
> >> CLOUDSTACK-### should be considdered a blocker"
> >> ad two: we have such a process, we vote by lazy consensus on technical
> >> issues on dev@
> >>
> >>>
> >>> To me it makes more sense to do this the other way round, that is, the
> person who found the issue raises the issue based on his understanding of
> the severity/impact. The person who is responsible for triaging (which in
> this case is the community) shall use their discretion to justify the
> severity and if it doesn't substantiate then downgrade/upgrade the same.
> >>
> >> this leaves teh community open to being taken hostage by a single
> >> person or a small group that keeps bombarding us with blockers. I am
> >> being paranoia by past experience.
> >>
> >>>
> >>> Isn't this the general engineering practice?
> >>
> >> Not to my knowledge, not in this case. Of course we can have a
> >> discussion about the semantics of 'blocker'. And then a user may be
> >> blocked but that is not this case: our release should be blocked is
> >> what blocker means to us. For all practical purposes we don't have a
> >> severity 'blocks user'.
> >>
> >>>
> >>> In addition, we'd have a guidelines on defect categorization for
> reference that can be looked up while raising a defect.
> >>
> >> that is a very good idea.
> >>
> >>>
> >>> Regards,
> >>> Somesh
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> >>> Sent: Friday, July 31, 2015 2:34 PM
> >>> To: dev
> >>> Subject: Re: Revisit Process for creating Blocker bugs
> >>>
> >>> -1 blocker means blocker and blocks a release. No one should be able
> >>> to block a release on their own. We should treat the critical category
> >>> as a staging area for those issues.
> >>>
> >>> On Fri, Jul 31, 2015 at 5:51 PM, Somesh Naidu <So...@citrix.com>
> wrote:
> >>>> +1
> >>>>
> >>>> Categorizing an issue as blocker/showstopper should need some kind of
> moderation. One possibility, voting and/or require approval from certain #
> of PMCs. Alternately, this could also be left to the discretion of the RM.
> >>>>
> >>>> Regards,
> >>>> Somesh
> >>>>
> >>>> -----Original Message-----
> >>>> From: Raja Pullela [mailto:raja.pullela@citrix.com]
> >>>> Sent: Friday, July 31, 2015 11:15 AM
> >>>> To: CloudStack Dev
> >>>> Subject: Revisit Process for creating Blocker bugs
> >>>>
> >>>> Hi,
> >>>>
> >>>> I am requesting to see if we can revisit the process for creating
> "blocker" defects.  I heard and do understand that someone can create a
> blocker defect and may not actively involve in closing it out and it
> doesn't help the product.  I am not clear if we are doing this at and
> around RC time - however it doesn't matter.
> >>>>
> >>>> IMHO, feel that someone's involvement should not be taken as a reason
> for incorrectly categorizing a defect, meaning a blocker defect being
> created as a Critical and opening up a discussion to review.  If no one
> supports the defect/issue, we will be putting out a release that has
> showstopper issues.
> >>>>
> >>>> Please share your thoughts and concerns for or against lifting this
> restriction!
> >>>>
> >>>> Raja
> >>>
> >>>
> >>>
> >>> --
> >>> Daan
> >>
> >>
> >>
> >> --
> >> Daan
> >
> >
> >
> > --
> > Daan
>
>
>
> --
> Daan
>



-- 
Daan

Re: Revisit Process for creating Blocker bugs

[Daan Hoogland <da...@gmail.com>]

kewl,

Are you sure btw, the openoffice page does state that blockers first have
to be discussed on the mailing list, which was I think the argument to
start this thread.

On Mon, Aug 3, 2015 at 8:20 PM, Somesh Naidu <So...@citrix.com>
wrote:

> Daan, that sounds perfect to me!
>
> Regards,
> Somesh
>
>
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Monday, August 03, 2015 4:59 AM
> To: dev
> Subject: Re: Revisit Process for creating Blocker bugs
>
> Raja, Somesh,
>
> I want to revise my stand on this slightly; If we make a page like the
> openoffice on Somesh shared which states in a little less abstract
> ways clear categories that define a blocker we can quicken our
> discussions on the subject. An RM could then quickly get feedback and
> close or lower blockers that were not according to those standards.
> The RM does, in those cases not have to be well informed on every
> aspect of ACS.
>
> the list from the OO page,
> <l>
> it is a regression in main functionality
> it is a crash in main functionality
> it is a freeze or loop in main functionality
> it is a security issue
> it is a privacy issue
> it is a data loss
> it is a build breaker on one or more of the generally supported platforms
> it is an important usability issue in Accessibility (A11Y)
> it is a legal issue
> it is a translation merge issue
> </l>
> , is on some points to vague to me to be usable. Also I would want to
> be more restrictive. We can not deal with blockers on components if no
> active community member use them, so the component/functionality part
> should include a strict definition. Also the main part should be well
> defined.
>
> The strictness I propose is only for accepting without discussion that
> an issue is a blocker. So anyone, RM, reporter or others can of course
> always start a discussion that any more or less trivial issue be
> regarded as blocker anyway.
>
> i want to have one remark on the page on blockers if we create it:
> "Please keep in mind that stopping a release, for what is a blocker to
> one user may block another user that is in dire need for added
> functionality and not blocked by the new issue."
>
> sound reasonable?
>
> On Sat, Aug 1, 2015 at 9:36 AM, Daan Hoogland <da...@gmail.com>
> wrote:
> > Thanks Somesh, It is a usefull link.
> >
> > Now if for instance an installation can not be used because no initial
> > zane can be created, this would be a showstopper. But if a release
> > does not have certain obscure features (even as regression) we have a
> > discussion. Not whether we should fix it. I am totally with you on
> > that. It does not block a release and does not render a deployment of
> > such a release completely useless. It will be useless for a group of
> > users while it may at the same time remove blockers from previous
> > releases for other groups of users.
> >
> > This dilemma I want to address by introducing the difference. I have
> > not seen much 'blocker's amongst the blockers that where reported in
> > cloudstack. There were some, sure but most were regressions that would
> > hinder some users and as we could well decide that these are blockers
> > (and I think we should in *most* cases). they block users and not
> > necessarily a release.
> >
> >
> >
> >
> > On Sat, Aug 1, 2015 at 12:32 AM, Somesh Naidu <So...@citrix.com>
> wrote:
> >> Daan,
> >>
> >> I was using the term "blocker" in context of a release and hence
> suggesting involvement of RM in getting a closure.
> >>
> >> In terms of defect categorization, I found this both relevant and
> helpful - https://wiki.openoffice.org/wiki/Showstopper.
> >>
> >> Regards,
> >> Somesh
> >>
> >>
> >> -----Original Message-----
> >> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> >> Sent: Friday, July 31, 2015 5:52 PM
> >> To: dev
> >> Subject: Re: Revisit Process for creating Blocker bugs
> >>
> >> Somesh, please see my replies in line;
> >>
> >> On Fri, Jul 31, 2015 at 10:31 PM, Somesh Naidu <So...@citrix.com>
> wrote:
> >>> Daan,
> >>>
> >>> While I have the same opinion as you that "No one should be able to
> block a release on their own". I also agree that the issue should be posted
> to the ML for discussion and it is the responsibility of the person who
> posted the defect to do so.
> >>>
> >>> I am more concerned with the process. My concern is specifically
> around this comment from Raja "If no one supports the defect/issue, we will
> be putting out a release that has showstopper issues."
> >>>
> >>> I mean for one, there should be a way for someone to flag an issue as
> blocker/showstopper and two, ensure that there is an explicit decision
> being made on the severity.
> >>
> >> ad one: you can send a mail saying "in my opinion the issue
> >> CLOUDSTACK-### should be considdered a blocker"
> >> ad two: we have such a process, we vote by lazy consensus on technical
> >> issues on dev@
> >>
> >>>
> >>> To me it makes more sense to do this the other way round, that is, the
> person who found the issue raises the issue based on his understanding of
> the severity/impact. The person who is responsible for triaging (which in
> this case is the community) shall use their discretion to justify the
> severity and if it doesn't substantiate then downgrade/upgrade the same.
> >>
> >> this leaves teh community open to being taken hostage by a single
> >> person or a small group that keeps bombarding us with blockers. I am
> >> being paranoia by past experience.
> >>
> >>>
> >>> Isn't this the general engineering practice?
> >>
> >> Not to my knowledge, not in this case. Of course we can have a
> >> discussion about the semantics of 'blocker'. And then a user may be
> >> blocked but that is not this case: our release should be blocked is
> >> what blocker means to us. For all practical purposes we don't have a
> >> severity 'blocks user'.
> >>
> >>>
> >>> In addition, we'd have a guidelines on defect categorization for
> reference that can be looked up while raising a defect.
> >>
> >> that is a very good idea.
> >>
> >>>
> >>> Regards,
> >>> Somesh
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> >>> Sent: Friday, July 31, 2015 2:34 PM
> >>> To: dev
> >>> Subject: Re: Revisit Process for creating Blocker bugs
> >>>
> >>> -1 blocker means blocker and blocks a release. No one should be able
> >>> to block a release on their own. We should treat the critical category
> >>> as a staging area for those issues.
> >>>
> >>> On Fri, Jul 31, 2015 at 5:51 PM, Somesh Naidu <So...@citrix.com>
> wrote:
> >>>> +1
> >>>>
> >>>> Categorizing an issue as blocker/showstopper should need some kind of
> moderation. One possibility, voting and/or require approval from certain #
> of PMCs. Alternately, this could also be left to the discretion of the RM.
> >>>>
> >>>> Regards,
> >>>> Somesh
> >>>>
> >>>> -----Original Message-----
> >>>> From: Raja Pullela [mailto:raja.pullela@citrix.com]
> >>>> Sent: Friday, July 31, 2015 11:15 AM
> >>>> To: CloudStack Dev
> >>>> Subject: Revisit Process for creating Blocker bugs
> >>>>
> >>>> Hi,
> >>>>
> >>>> I am requesting to see if we can revisit the process for creating
> "blocker" defects.  I heard and do understand that someone can create a
> blocker defect and may not actively involve in closing it out and it
> doesn't help the product.  I am not clear if we are doing this at and
> around RC time - however it doesn't matter.
> >>>>
> >>>> IMHO, feel that someone's involvement should not be taken as a reason
> for incorrectly categorizing a defect, meaning a blocker defect being
> created as a Critical and opening up a discussion to review.  If no one
> supports the defect/issue, we will be putting out a release that has
> showstopper issues.
> >>>>
> >>>> Please share your thoughts and concerns for or against lifting this
> restriction!
> >>>>
> >>>> Raja
> >>>
> >>>
> >>>
> >>> --
> >>> Daan
> >>
> >>
> >>
> >> --
> >> Daan
> >
> >
> >
> > --
> > Daan
>
>
>
> --
> Daan
>



-- 
Daan

RE: Revisit Process for creating Blocker bugs

[Somesh Naidu <So...@citrix.com>]

Daan, that sounds perfect to me!

Regards,
Somesh


-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
Sent: Monday, August 03, 2015 4:59 AM
To: dev
Subject: Re: Revisit Process for creating Blocker bugs

Raja, Somesh,

I want to revise my stand on this slightly; If we make a page like the
openoffice on Somesh shared which states in a little less abstract
ways clear categories that define a blocker we can quicken our
discussions on the subject. An RM could then quickly get feedback and
close or lower blockers that were not according to those standards.
The RM does, in those cases not have to be well informed on every
aspect of ACS.

the list from the OO page,
<l>
it is a regression in main functionality
it is a crash in main functionality
it is a freeze or loop in main functionality
it is a security issue
it is a privacy issue
it is a data loss
it is a build breaker on one or more of the generally supported platforms
it is an important usability issue in Accessibility (A11Y)
it is a legal issue
it is a translation merge issue
</l>
, is on some points to vague to me to be usable. Also I would want to
be more restrictive. We can not deal with blockers on components if no
active community member use them, so the component/functionality part
should include a strict definition. Also the main part should be well
defined.

The strictness I propose is only for accepting without discussion that
an issue is a blocker. So anyone, RM, reporter or others can of course
always start a discussion that any more or less trivial issue be
regarded as blocker anyway.

i want to have one remark on the page on blockers if we create it:
"Please keep in mind that stopping a release, for what is a blocker to
one user may block another user that is in dire need for added
functionality and not blocked by the new issue."

sound reasonable?

On Sat, Aug 1, 2015 at 9:36 AM, Daan Hoogland <da...@gmail.com> wrote:
> Thanks Somesh, It is a usefull link.
>
> Now if for instance an installation can not be used because no initial
> zane can be created, this would be a showstopper. But if a release
> does not have certain obscure features (even as regression) we have a
> discussion. Not whether we should fix it. I am totally with you on
> that. It does not block a release and does not render a deployment of
> such a release completely useless. It will be useless for a group of
> users while it may at the same time remove blockers from previous
> releases for other groups of users.
>
> This dilemma I want to address by introducing the difference. I have
> not seen much 'blocker's amongst the blockers that where reported in
> cloudstack. There were some, sure but most were regressions that would
> hinder some users and as we could well decide that these are blockers
> (and I think we should in *most* cases). they block users and not
> necessarily a release.
>
>
>
>
> On Sat, Aug 1, 2015 at 12:32 AM, Somesh Naidu <So...@citrix.com> wrote:
>> Daan,
>>
>> I was using the term "blocker" in context of a release and hence suggesting involvement of RM in getting a closure.
>>
>> In terms of defect categorization, I found this both relevant and helpful - https://wiki.openoffice.org/wiki/Showstopper.
>>
>> Regards,
>> Somesh
>>
>>
>> -----Original Message-----
>> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
>> Sent: Friday, July 31, 2015 5:52 PM
>> To: dev
>> Subject: Re: Revisit Process for creating Blocker bugs
>>
>> Somesh, please see my replies in line;
>>
>> On Fri, Jul 31, 2015 at 10:31 PM, Somesh Naidu <So...@citrix.com> wrote:
>>> Daan,
>>>
>>> While I have the same opinion as you that "No one should be able to block a release on their own". I also agree that the issue should be posted to the ML for discussion and it is the responsibility of the person who posted the defect to do so.
>>>
>>> I am more concerned with the process. My concern is specifically around this comment from Raja "If no one supports the defect/issue, we will be putting out a release that has showstopper issues."
>>>
>>> I mean for one, there should be a way for someone to flag an issue as blocker/showstopper and two, ensure that there is an explicit decision being made on the severity.
>>
>> ad one: you can send a mail saying "in my opinion the issue
>> CLOUDSTACK-### should be considdered a blocker"
>> ad two: we have such a process, we vote by lazy consensus on technical
>> issues on dev@
>>
>>>
>>> To me it makes more sense to do this the other way round, that is, the person who found the issue raises the issue based on his understanding of the severity/impact. The person who is responsible for triaging (which in this case is the community) shall use their discretion to justify the severity and if it doesn't substantiate then downgrade/upgrade the same.
>>
>> this leaves teh community open to being taken hostage by a single
>> person or a small group that keeps bombarding us with blockers. I am
>> being paranoia by past experience.
>>
>>>
>>> Isn't this the general engineering practice?
>>
>> Not to my knowledge, not in this case. Of course we can have a
>> discussion about the semantics of 'blocker'. And then a user may be
>> blocked but that is not this case: our release should be blocked is
>> what blocker means to us. For all practical purposes we don't have a
>> severity 'blocks user'.
>>
>>>
>>> In addition, we'd have a guidelines on defect categorization for reference that can be looked up while raising a defect.
>>
>> that is a very good idea.
>>
>>>
>>> Regards,
>>> Somesh
>>>
>>>
>>> -----Original Message-----
>>> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
>>> Sent: Friday, July 31, 2015 2:34 PM
>>> To: dev
>>> Subject: Re: Revisit Process for creating Blocker bugs
>>>
>>> -1 blocker means blocker and blocks a release. No one should be able
>>> to block a release on their own. We should treat the critical category
>>> as a staging area for those issues.
>>>
>>> On Fri, Jul 31, 2015 at 5:51 PM, Somesh Naidu <So...@citrix.com> wrote:
>>>> +1
>>>>
>>>> Categorizing an issue as blocker/showstopper should need some kind of moderation. One possibility, voting and/or require approval from certain # of PMCs. Alternately, this could also be left to the discretion of the RM.
>>>>
>>>> Regards,
>>>> Somesh
>>>>
>>>> -----Original Message-----
>>>> From: Raja Pullela [mailto:raja.pullela@citrix.com]
>>>> Sent: Friday, July 31, 2015 11:15 AM
>>>> To: CloudStack Dev
>>>> Subject: Revisit Process for creating Blocker bugs
>>>>
>>>> Hi,
>>>>
>>>> I am requesting to see if we can revisit the process for creating "blocker" defects.  I heard and do understand that someone can create a blocker defect and may not actively involve in closing it out and it doesn't help the product.  I am not clear if we are doing this at and around RC time - however it doesn't matter.
>>>>
>>>> IMHO, feel that someone's involvement should not be taken as a reason for incorrectly categorizing a defect, meaning a blocker defect being created as a Critical and opening up a discussion to review.  If no one supports the defect/issue, we will be putting out a release that has showstopper issues.
>>>>
>>>> Please share your thoughts and concerns for or against lifting this restriction!
>>>>
>>>> Raja
>>>
>>>
>>>
>>> --
>>> Daan
>>
>>
>>
>> --
>> Daan
>
>
>
> --
> Daan



-- 
Daan

Re: Revisit Process for creating Blocker bugs

[Daan Hoogland <da...@gmail.com>]

Raja, Somesh,

I want to revise my stand on this slightly; If we make a page like the
openoffice on Somesh shared which states in a little less abstract
ways clear categories that define a blocker we can quicken our
discussions on the subject. An RM could then quickly get feedback and
close or lower blockers that were not according to those standards.
The RM does, in those cases not have to be well informed on every
aspect of ACS.

the list from the OO page,
<l>
it is a regression in main functionality
it is a crash in main functionality
it is a freeze or loop in main functionality
it is a security issue
it is a privacy issue
it is a data loss
it is a build breaker on one or more of the generally supported platforms
it is an important usability issue in Accessibility (A11Y)
it is a legal issue
it is a translation merge issue
</l>
, is on some points to vague to me to be usable. Also I would want to
be more restrictive. We can not deal with blockers on components if no
active community member use them, so the component/functionality part
should include a strict definition. Also the main part should be well
defined.

The strictness I propose is only for accepting without discussion that
an issue is a blocker. So anyone, RM, reporter or others can of course
always start a discussion that any more or less trivial issue be
regarded as blocker anyway.

i want to have one remark on the page on blockers if we create it:
"Please keep in mind that stopping a release, for what is a blocker to
one user may block another user that is in dire need for added
functionality and not blocked by the new issue."

sound reasonable?

On Sat, Aug 1, 2015 at 9:36 AM, Daan Hoogland <da...@gmail.com> wrote:
> Thanks Somesh, It is a usefull link.
>
> Now if for instance an installation can not be used because no initial
> zane can be created, this would be a showstopper. But if a release
> does not have certain obscure features (even as regression) we have a
> discussion. Not whether we should fix it. I am totally with you on
> that. It does not block a release and does not render a deployment of
> such a release completely useless. It will be useless for a group of
> users while it may at the same time remove blockers from previous
> releases for other groups of users.
>
> This dilemma I want to address by introducing the difference. I have
> not seen much 'blocker's amongst the blockers that where reported in
> cloudstack. There were some, sure but most were regressions that would
> hinder some users and as we could well decide that these are blockers
> (and I think we should in *most* cases). they block users and not
> necessarily a release.
>
>
>
>
> On Sat, Aug 1, 2015 at 12:32 AM, Somesh Naidu <So...@citrix.com> wrote:
>> Daan,
>>
>> I was using the term "blocker" in context of a release and hence suggesting involvement of RM in getting a closure.
>>
>> In terms of defect categorization, I found this both relevant and helpful - https://wiki.openoffice.org/wiki/Showstopper.
>>
>> Regards,
>> Somesh
>>
>>
>> -----Original Message-----
>> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
>> Sent: Friday, July 31, 2015 5:52 PM
>> To: dev
>> Subject: Re: Revisit Process for creating Blocker bugs
>>
>> Somesh, please see my replies in line;
>>
>> On Fri, Jul 31, 2015 at 10:31 PM, Somesh Naidu <So...@citrix.com> wrote:
>>> Daan,
>>>
>>> While I have the same opinion as you that "No one should be able to block a release on their own". I also agree that the issue should be posted to the ML for discussion and it is the responsibility of the person who posted the defect to do so.
>>>
>>> I am more concerned with the process. My concern is specifically around this comment from Raja "If no one supports the defect/issue, we will be putting out a release that has showstopper issues."
>>>
>>> I mean for one, there should be a way for someone to flag an issue as blocker/showstopper and two, ensure that there is an explicit decision being made on the severity.
>>
>> ad one: you can send a mail saying "in my opinion the issue
>> CLOUDSTACK-### should be considdered a blocker"
>> ad two: we have such a process, we vote by lazy consensus on technical
>> issues on dev@
>>
>>>
>>> To me it makes more sense to do this the other way round, that is, the person who found the issue raises the issue based on his understanding of the severity/impact. The person who is responsible for triaging (which in this case is the community) shall use their discretion to justify the severity and if it doesn't substantiate then downgrade/upgrade the same.
>>
>> this leaves teh community open to being taken hostage by a single
>> person or a small group that keeps bombarding us with blockers. I am
>> being paranoia by past experience.
>>
>>>
>>> Isn't this the general engineering practice?
>>
>> Not to my knowledge, not in this case. Of course we can have a
>> discussion about the semantics of 'blocker'. And then a user may be
>> blocked but that is not this case: our release should be blocked is
>> what blocker means to us. For all practical purposes we don't have a
>> severity 'blocks user'.
>>
>>>
>>> In addition, we'd have a guidelines on defect categorization for reference that can be looked up while raising a defect.
>>
>> that is a very good idea.
>>
>>>
>>> Regards,
>>> Somesh
>>>
>>>
>>> -----Original Message-----
>>> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
>>> Sent: Friday, July 31, 2015 2:34 PM
>>> To: dev
>>> Subject: Re: Revisit Process for creating Blocker bugs
>>>
>>> -1 blocker means blocker and blocks a release. No one should be able
>>> to block a release on their own. We should treat the critical category
>>> as a staging area for those issues.
>>>
>>> On Fri, Jul 31, 2015 at 5:51 PM, Somesh Naidu <So...@citrix.com> wrote:
>>>> +1
>>>>
>>>> Categorizing an issue as blocker/showstopper should need some kind of moderation. One possibility, voting and/or require approval from certain # of PMCs. Alternately, this could also be left to the discretion of the RM.
>>>>
>>>> Regards,
>>>> Somesh
>>>>
>>>> -----Original Message-----
>>>> From: Raja Pullela [mailto:raja.pullela@citrix.com]
>>>> Sent: Friday, July 31, 2015 11:15 AM
>>>> To: CloudStack Dev
>>>> Subject: Revisit Process for creating Blocker bugs
>>>>
>>>> Hi,
>>>>
>>>> I am requesting to see if we can revisit the process for creating "blocker" defects.  I heard and do understand that someone can create a blocker defect and may not actively involve in closing it out and it doesn't help the product.  I am not clear if we are doing this at and around RC time - however it doesn't matter.
>>>>
>>>> IMHO, feel that someone's involvement should not be taken as a reason for incorrectly categorizing a defect, meaning a blocker defect being created as a Critical and opening up a discussion to review.  If no one supports the defect/issue, we will be putting out a release that has showstopper issues.
>>>>
>>>> Please share your thoughts and concerns for or against lifting this restriction!
>>>>
>>>> Raja
>>>
>>>
>>>
>>> --
>>> Daan
>>
>>
>>
>> --
>> Daan
>
>
>
> --
> Daan



-- 
Daan

Re: Revisit Process for creating Blocker bugs

[Daan Hoogland <da...@gmail.com>]

Thanks Somesh, It is a usefull link.

Now if for instance an installation can not be used because no initial
zane can be created, this would be a showstopper. But if a release
does not have certain obscure features (even as regression) we have a
discussion. Not whether we should fix it. I am totally with you on
that. It does not block a release and does not render a deployment of
such a release completely useless. It will be useless for a group of
users while it may at the same time remove blockers from previous
releases for other groups of users.

This dilemma I want to address by introducing the difference. I have
not seen much 'blocker's amongst the blockers that where reported in
cloudstack. There were some, sure but most were regressions that would
hinder some users and as we could well decide that these are blockers
(and I think we should in *most* cases). they block users and not
necessarily a release.




On Sat, Aug 1, 2015 at 12:32 AM, Somesh Naidu <So...@citrix.com> wrote:
> Daan,
>
> I was using the term "blocker" in context of a release and hence suggesting involvement of RM in getting a closure.
>
> In terms of defect categorization, I found this both relevant and helpful - https://wiki.openoffice.org/wiki/Showstopper.
>
> Regards,
> Somesh
>
>
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Friday, July 31, 2015 5:52 PM
> To: dev
> Subject: Re: Revisit Process for creating Blocker bugs
>
> Somesh, please see my replies in line;
>
> On Fri, Jul 31, 2015 at 10:31 PM, Somesh Naidu <So...@citrix.com> wrote:
>> Daan,
>>
>> While I have the same opinion as you that "No one should be able to block a release on their own". I also agree that the issue should be posted to the ML for discussion and it is the responsibility of the person who posted the defect to do so.
>>
>> I am more concerned with the process. My concern is specifically around this comment from Raja "If no one supports the defect/issue, we will be putting out a release that has showstopper issues."
>>
>> I mean for one, there should be a way for someone to flag an issue as blocker/showstopper and two, ensure that there is an explicit decision being made on the severity.
>
> ad one: you can send a mail saying "in my opinion the issue
> CLOUDSTACK-### should be considdered a blocker"
> ad two: we have such a process, we vote by lazy consensus on technical
> issues on dev@
>
>>
>> To me it makes more sense to do this the other way round, that is, the person who found the issue raises the issue based on his understanding of the severity/impact. The person who is responsible for triaging (which in this case is the community) shall use their discretion to justify the severity and if it doesn't substantiate then downgrade/upgrade the same.
>
> this leaves teh community open to being taken hostage by a single
> person or a small group that keeps bombarding us with blockers. I am
> being paranoia by past experience.
>
>>
>> Isn't this the general engineering practice?
>
> Not to my knowledge, not in this case. Of course we can have a
> discussion about the semantics of 'blocker'. And then a user may be
> blocked but that is not this case: our release should be blocked is
> what blocker means to us. For all practical purposes we don't have a
> severity 'blocks user'.
>
>>
>> In addition, we'd have a guidelines on defect categorization for reference that can be looked up while raising a defect.
>
> that is a very good idea.
>
>>
>> Regards,
>> Somesh
>>
>>
>> -----Original Message-----
>> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
>> Sent: Friday, July 31, 2015 2:34 PM
>> To: dev
>> Subject: Re: Revisit Process for creating Blocker bugs
>>
>> -1 blocker means blocker and blocks a release. No one should be able
>> to block a release on their own. We should treat the critical category
>> as a staging area for those issues.
>>
>> On Fri, Jul 31, 2015 at 5:51 PM, Somesh Naidu <So...@citrix.com> wrote:
>>> +1
>>>
>>> Categorizing an issue as blocker/showstopper should need some kind of moderation. One possibility, voting and/or require approval from certain # of PMCs. Alternately, this could also be left to the discretion of the RM.
>>>
>>> Regards,
>>> Somesh
>>>
>>> -----Original Message-----
>>> From: Raja Pullela [mailto:raja.pullela@citrix.com]
>>> Sent: Friday, July 31, 2015 11:15 AM
>>> To: CloudStack Dev
>>> Subject: Revisit Process for creating Blocker bugs
>>>
>>> Hi,
>>>
>>> I am requesting to see if we can revisit the process for creating "blocker" defects.  I heard and do understand that someone can create a blocker defect and may not actively involve in closing it out and it doesn't help the product.  I am not clear if we are doing this at and around RC time - however it doesn't matter.
>>>
>>> IMHO, feel that someone's involvement should not be taken as a reason for incorrectly categorizing a defect, meaning a blocker defect being created as a Critical and opening up a discussion to review.  If no one supports the defect/issue, we will be putting out a release that has showstopper issues.
>>>
>>> Please share your thoughts and concerns for or against lifting this restriction!
>>>
>>> Raja
>>
>>
>>
>> --
>> Daan
>
>
>
> --
> Daan



-- 
Daan

RE: Revisit Process for creating Blocker bugs

[Somesh Naidu <So...@citrix.com>]

Daan,

I was using the term "blocker" in context of a release and hence suggesting involvement of RM in getting a closure.

In terms of defect categorization, I found this both relevant and helpful - https://wiki.openoffice.org/wiki/Showstopper.

Regards,
Somesh


-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
Sent: Friday, July 31, 2015 5:52 PM
To: dev
Subject: Re: Revisit Process for creating Blocker bugs

Somesh, please see my replies in line;

On Fri, Jul 31, 2015 at 10:31 PM, Somesh Naidu <So...@citrix.com> wrote:
> Daan,
>
> While I have the same opinion as you that "No one should be able to block a release on their own". I also agree that the issue should be posted to the ML for discussion and it is the responsibility of the person who posted the defect to do so.
>
> I am more concerned with the process. My concern is specifically around this comment from Raja "If no one supports the defect/issue, we will be putting out a release that has showstopper issues."
>
> I mean for one, there should be a way for someone to flag an issue as blocker/showstopper and two, ensure that there is an explicit decision being made on the severity.

ad one: you can send a mail saying "in my opinion the issue
CLOUDSTACK-### should be considdered a blocker"
ad two: we have such a process, we vote by lazy consensus on technical
issues on dev@

>
> To me it makes more sense to do this the other way round, that is, the person who found the issue raises the issue based on his understanding of the severity/impact. The person who is responsible for triaging (which in this case is the community) shall use their discretion to justify the severity and if it doesn't substantiate then downgrade/upgrade the same.

this leaves teh community open to being taken hostage by a single
person or a small group that keeps bombarding us with blockers. I am
being paranoia by past experience.

>
> Isn't this the general engineering practice?

Not to my knowledge, not in this case. Of course we can have a
discussion about the semantics of 'blocker'. And then a user may be
blocked but that is not this case: our release should be blocked is
what blocker means to us. For all practical purposes we don't have a
severity 'blocks user'.

>
> In addition, we'd have a guidelines on defect categorization for reference that can be looked up while raising a defect.

that is a very good idea.

>
> Regards,
> Somesh
>
>
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Friday, July 31, 2015 2:34 PM
> To: dev
> Subject: Re: Revisit Process for creating Blocker bugs
>
> -1 blocker means blocker and blocks a release. No one should be able
> to block a release on their own. We should treat the critical category
> as a staging area for those issues.
>
> On Fri, Jul 31, 2015 at 5:51 PM, Somesh Naidu <So...@citrix.com> wrote:
>> +1
>>
>> Categorizing an issue as blocker/showstopper should need some kind of moderation. One possibility, voting and/or require approval from certain # of PMCs. Alternately, this could also be left to the discretion of the RM.
>>
>> Regards,
>> Somesh
>>
>> -----Original Message-----
>> From: Raja Pullela [mailto:raja.pullela@citrix.com]
>> Sent: Friday, July 31, 2015 11:15 AM
>> To: CloudStack Dev
>> Subject: Revisit Process for creating Blocker bugs
>>
>> Hi,
>>
>> I am requesting to see if we can revisit the process for creating "blocker" defects.  I heard and do understand that someone can create a blocker defect and may not actively involve in closing it out and it doesn't help the product.  I am not clear if we are doing this at and around RC time - however it doesn't matter.
>>
>> IMHO, feel that someone's involvement should not be taken as a reason for incorrectly categorizing a defect, meaning a blocker defect being created as a Critical and opening up a discussion to review.  If no one supports the defect/issue, we will be putting out a release that has showstopper issues.
>>
>> Please share your thoughts and concerns for or against lifting this restriction!
>>
>> Raja
>
>
>
> --
> Daan



-- 
Daan

Re: Revisit Process for creating Blocker bugs

[Daan Hoogland <da...@gmail.com>]

Somesh, please see my replies in line;

On Fri, Jul 31, 2015 at 10:31 PM, Somesh Naidu <So...@citrix.com> wrote:
> Daan,
>
> While I have the same opinion as you that "No one should be able to block a release on their own". I also agree that the issue should be posted to the ML for discussion and it is the responsibility of the person who posted the defect to do so.
>
> I am more concerned with the process. My concern is specifically around this comment from Raja "If no one supports the defect/issue, we will be putting out a release that has showstopper issues."
>
> I mean for one, there should be a way for someone to flag an issue as blocker/showstopper and two, ensure that there is an explicit decision being made on the severity.

ad one: you can send a mail saying "in my opinion the issue
CLOUDSTACK-### should be considdered a blocker"
ad two: we have such a process, we vote by lazy consensus on technical
issues on dev@

>
> To me it makes more sense to do this the other way round, that is, the person who found the issue raises the issue based on his understanding of the severity/impact. The person who is responsible for triaging (which in this case is the community) shall use their discretion to justify the severity and if it doesn't substantiate then downgrade/upgrade the same.

this leaves teh community open to being taken hostage by a single
person or a small group that keeps bombarding us with blockers. I am
being paranoia by past experience.

>
> Isn't this the general engineering practice?

Not to my knowledge, not in this case. Of course we can have a
discussion about the semantics of 'blocker'. And then a user may be
blocked but that is not this case: our release should be blocked is
what blocker means to us. For all practical purposes we don't have a
severity 'blocks user'.

>
> In addition, we'd have a guidelines on defect categorization for reference that can be looked up while raising a defect.

that is a very good idea.

>
> Regards,
> Somesh
>
>
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Friday, July 31, 2015 2:34 PM
> To: dev
> Subject: Re: Revisit Process for creating Blocker bugs
>
> -1 blocker means blocker and blocks a release. No one should be able
> to block a release on their own. We should treat the critical category
> as a staging area for those issues.
>
> On Fri, Jul 31, 2015 at 5:51 PM, Somesh Naidu <So...@citrix.com> wrote:
>> +1
>>
>> Categorizing an issue as blocker/showstopper should need some kind of moderation. One possibility, voting and/or require approval from certain # of PMCs. Alternately, this could also be left to the discretion of the RM.
>>
>> Regards,
>> Somesh
>>
>> -----Original Message-----
>> From: Raja Pullela [mailto:raja.pullela@citrix.com]
>> Sent: Friday, July 31, 2015 11:15 AM
>> To: CloudStack Dev
>> Subject: Revisit Process for creating Blocker bugs
>>
>> Hi,
>>
>> I am requesting to see if we can revisit the process for creating "blocker" defects.  I heard and do understand that someone can create a blocker defect and may not actively involve in closing it out and it doesn't help the product.  I am not clear if we are doing this at and around RC time - however it doesn't matter.
>>
>> IMHO, feel that someone's involvement should not be taken as a reason for incorrectly categorizing a defect, meaning a blocker defect being created as a Critical and opening up a discussion to review.  If no one supports the defect/issue, we will be putting out a release that has showstopper issues.
>>
>> Please share your thoughts and concerns for or against lifting this restriction!
>>
>> Raja
>
>
>
> --
> Daan



-- 
Daan

RE: Revisit Process for creating Blocker bugs

[Somesh Naidu <So...@citrix.com>]

Daan,

While I have the same opinion as you that "No one should be able to block a release on their own". I also agree that the issue should be posted to the ML for discussion and it is the responsibility of the person who posted the defect to do so.

I am more concerned with the process. My concern is specifically around this comment from Raja "If no one supports the defect/issue, we will be putting out a release that has showstopper issues."

I mean for one, there should be a way for someone to flag an issue as blocker/showstopper and two, ensure that there is an explicit decision being made on the severity.

To me it makes more sense to do this the other way round, that is, the person who found the issue raises the issue based on his understanding of the severity/impact. The person who is responsible for triaging (which in this case is the community) shall use their discretion to justify the severity and if it doesn't substantiate then downgrade/upgrade the same. 

Isn't this the general engineering practice?

In addition, we'd have a guidelines on defect categorization for reference that can be looked up while raising a defect.

Regards,
Somesh


-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
Sent: Friday, July 31, 2015 2:34 PM
To: dev
Subject: Re: Revisit Process for creating Blocker bugs

-1 blocker means blocker and blocks a release. No one should be able
to block a release on their own. We should treat the critical category
as a staging area for those issues.

On Fri, Jul 31, 2015 at 5:51 PM, Somesh Naidu <So...@citrix.com> wrote:
> +1
>
> Categorizing an issue as blocker/showstopper should need some kind of moderation. One possibility, voting and/or require approval from certain # of PMCs. Alternately, this could also be left to the discretion of the RM.
>
> Regards,
> Somesh
>
> -----Original Message-----
> From: Raja Pullela [mailto:raja.pullela@citrix.com]
> Sent: Friday, July 31, 2015 11:15 AM
> To: CloudStack Dev
> Subject: Revisit Process for creating Blocker bugs
>
> Hi,
>
> I am requesting to see if we can revisit the process for creating "blocker" defects.  I heard and do understand that someone can create a blocker defect and may not actively involve in closing it out and it doesn't help the product.  I am not clear if we are doing this at and around RC time - however it doesn't matter.
>
> IMHO, feel that someone's involvement should not be taken as a reason for incorrectly categorizing a defect, meaning a blocker defect being created as a Critical and opening up a discussion to review.  If no one supports the defect/issue, we will be putting out a release that has showstopper issues.
>
> Please share your thoughts and concerns for or against lifting this restriction!
>
> Raja



-- 
Daan

Re: Revisit Process for creating Blocker bugs

[Daan Hoogland <da...@gmail.com>]

-1 blocker means blocker and blocks a release. No one should be able
to block a release on their own. We should treat the critical category
as a staging area for those issues.

On Fri, Jul 31, 2015 at 5:51 PM, Somesh Naidu <So...@citrix.com> wrote:
> +1
>
> Categorizing an issue as blocker/showstopper should need some kind of moderation. One possibility, voting and/or require approval from certain # of PMCs. Alternately, this could also be left to the discretion of the RM.
>
> Regards,
> Somesh
>
> -----Original Message-----
> From: Raja Pullela [mailto:raja.pullela@citrix.com]
> Sent: Friday, July 31, 2015 11:15 AM
> To: CloudStack Dev
> Subject: Revisit Process for creating Blocker bugs
>
> Hi,
>
> I am requesting to see if we can revisit the process for creating "blocker" defects.  I heard and do understand that someone can create a blocker defect and may not actively involve in closing it out and it doesn't help the product.  I am not clear if we are doing this at and around RC time - however it doesn't matter.
>
> IMHO, feel that someone's involvement should not be taken as a reason for incorrectly categorizing a defect, meaning a blocker defect being created as a Critical and opening up a discussion to review.  If no one supports the defect/issue, we will be putting out a release that has showstopper issues.
>
> Please share your thoughts and concerns for or against lifting this restriction!
>
> Raja



-- 
Daan

RE: Revisit Process for creating Blocker bugs

[Somesh Naidu <So...@citrix.com>]

+1

Categorizing an issue as blocker/showstopper should need some kind of moderation. One possibility, voting and/or require approval from certain # of PMCs. Alternately, this could also be left to the discretion of the RM. 

Regards,
Somesh

-----Original Message-----
From: Raja Pullela [mailto:raja.pullela@citrix.com] 
Sent: Friday, July 31, 2015 11:15 AM
To: CloudStack Dev
Subject: Revisit Process for creating Blocker bugs

Hi,

I am requesting to see if we can revisit the process for creating "blocker" defects.  I heard and do understand that someone can create a blocker defect and may not actively involve in closing it out and it doesn't help the product.  I am not clear if we are doing this at and around RC time - however it doesn't matter.

IMHO, feel that someone's involvement should not be taken as a reason for incorrectly categorizing a defect, meaning a blocker defect being created as a Critical and opening up a discussion to review.  If no one supports the defect/issue, we will be putting out a release that has showstopper issues.  

Please share your thoughts and concerns for or against lifting this restriction!

Raja