Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAGQtxvYW_YUe6Yk2HFCOcZg8J3dFNFUz_he-WDJ+Ot+gft6HOA@mail.gmail.com>
References: <62852B62-345F-4C31-BCF7-296D28A92E66@citrix.com>
 <BC047208AFA8C3429141743ADC8C561D757AA13F@FTLPEX01CL02.citrite.net>
 <CAGQtxvZMweDwddBJstF9jt7pocvAVYMNc6=QTb9dkGyrtDHU7A@mail.gmail.com>
 <BC047208AFA8C3429141743ADC8C561D757AA4AC@FTLPEX01CL02.citrite.net>
 <CAGQtxvbiBJnLJ+nq4YVEu9sdfV0wOqGcHEpWMnD8Kv4Nm_VmBQ@mail.gmail.com>
 <BC047208AFA8C3429141743ADC8C561D757AA611@FTLPEX01CL02.citrite.net>
 <CAGQtxvYW_YUe6Yk2HFCOcZg8J3dFNFUz_he-WDJ+Ot+gft6HOA@mail.gmail.com>
From: Daan Hoogland <daan.hoogland@gmail.com>
Date: Mon, 3 Aug 2015 10:58:31 +0200
Message-ID: 
 <CAGQtxvb17=m3drJN50dqTH4+VEd47Js=qUPnchQyuayPKpugZw@mail.gmail.com>
Subject: Re: Revisit Process for creating Blocker bugs
To: dev <dev@cloudstack.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <daan.hoogland@gmail.com> wro=
te:
> 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 <Somesh.Naidu@citrix.com> w=
rote:
>> Daan,
>>
>> I was using the term "blocker" in context of a release and hence suggest=
ing involvement of RM in getting a closure.
>>
>> In terms of defect categorization, I found this both relevant and helpfu=
l - 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 <Somesh.Naidu@citrix.com>=
 wrote:
>>> Daan,
>>>
>>> While I have the same opinion as you that "No one should be able to blo=
ck 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 poste=
d 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 pu=
tting out a release that has showstopper issues."
>>>
>>> I mean for one, there should be a way for someone to flag an issue as b=
locker/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 t=
he severity/impact. The person who is responsible for triaging (which in th=
is case is the community) shall use their discretion to justify the severit=
y 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 refere=
nce 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 <Somesh.Naidu@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 "blo=
cker" 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 - h=
owever 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 creat=
ed 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 is=
sues.
>>>>
>>>> Please share your thoughts and concerns for or against lifting this re=
striction!
>>>>
>>>> Raja
>>>
>>>
>>>
>>> --
>>> Daan
>>
>>
>>
>> --
>> Daan
>
>
>
> --
> Daan


--=20
Daan