cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Revisit Process for creating Blocker bugs
Date Tue, 11 Aug 2015 00:32:28 GMT
"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 <Somesh.Naidu@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 <raja.pullela@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 <dev@cloudstack.apache.org>
> > Subject: Re: Revisit Process for creating Blocker bugs
> >
> > Koushik, that would be true if we had our upgrade process in order.
> >
> > On Wed, Aug 5, 2015 at 7:14 AM, Koushik Das <koushik.das@citrix.com>
> wrote:
> >
> >> If there is a group of users in dire need for a specific feature they
> >> can always take the code and use it. No need to wait for an official
> release.
> >> Official release should adhere to quality guidelines (at least in
> >> terms of any reported regressions) even if it means release getting
> delayed.
> >>
> >>
> >> On 05-Aug-2015, at 2:39 AM, Daan Hoogland <daan.hoogland@gmail.com>
> wrote:
> >>
> >>> Yes we can if there is a group of users that don't use it but are in
> >>> dire need far another feature. We just have to document and market
> >>> it properly
> >>>
> >>> On Tue, Aug 4, 2015 at 6:48 PM, Ramanath Katru
> >>> <ramanath.katru@citrix.com> wrote:
> >>>> Daan,
> >>>>
> >>>> I beg to differ. This is very much a product issue. We cannot
> >>>> knowingly
> >> release with an existing/working functionality broken. Especially if
> >> it is one of the features that users expect to be there. Remote Access
> >> VPN is an example. Right now this functionality is broken.
> >>>>
> >>>> Ram Katru
> >>>>
> >>>> -----Original Message-----
> >>>> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> >>>> Sent: Tuesday, August 4, 2015 4:57 PM
> >>>> To: dev <dev@cloudstack.apache.org>
> >>>> Subject: Re: Revisit Process for creating Blocker bugs
> >>>>
> >>>> Ram,
> >>>>
> >>>> This is a marketing issue, not a release issue. making a release or
> >> marketing it to the general public are two different things.
> >>>>
> >>>> Daan
> >>>>
> >>>> On Tue, Aug 4, 2015 at 12:41 PM, Ramanath Katru <
> >> ramanath.katru@citrix.com> wrote:
> >>>>> While we can say if a bug doesn’t effect "majority" of current
> >>>>> users,
> >> we can go ahead and release, but we should also look at a product
> >> perspective not just release perspective. There are some features that
> >> are important for cloudstack as a product and these cannot be broken
> >> in a release. If we do not evaluate from a product perspective, then
> >> we will be turning potential new users away.
> >>>>>
> >>>>> Ram Katru
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> >>>>> Sent: Tuesday, August 4, 2015 1:54 AM
> >>>>> To: dev <dev@cloudstack.apache.org>
> >>>>> Subject: Re: Revisit Process for creating Blocker bugs
> >>>>>
> >>>>> On Mon, Aug 3, 2015 at 10:16 PM, Somesh Naidu
> >>>>> <Somesh.Naidu@citrix.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I would like to add that while the # of users affected is
> >>>>>> definitely a major factor when ascertaining severity of an issue,
> >>>>>> should we not consider the technical scope and/or use-case of
a
> >>>>>> defect. For example, let's say there is only one user using
basic
> >>>>>> zone setup with VMware in the community but the bug/regression
> >>>>>> has caused a major failure like "No provisioning of VMs". Would
> >>>>>> this be considered a
> >> release blocker?
> >>>>>>
> >>>>>
> >>>>> This is exactly the kind of discussion we need to have when such
a
> >> case comes by. For this as purely hypothetical case I would say,
> release.
> >> We can not have other users abstain from badly needed features because
> >> one can not share in the joy. We would have to release a fix for this
> >> afterwards.
> >>>>>
> >>>>> just a 0.02 in virtual currency
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Daan
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Daan
> >>>
> >>>
> >>>
> >>> --
> >>> Daan
> >>
> >>
> >
> >
> > --
> > Daan
>
>


-- 
*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>*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message