cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
Subject Re: [DISCUSS] Release 4.4
Date Wed, 11 Jun 2014 20:54:54 GMT


On 6/11/14, 1:45 PM, "Daan Hoogland" <daan.hoogland@gmail.com> wrote:

>I agree, but I wouldn't pin 'blocker' by a definition of the nature of
>the defect. A blocker is something that blocks the community at large
>from releasing. What you define here would be useful for more vague
>prio definitions like 'critical', though. Of course a major defect in
>any of the hypervisor - or network - or storage types can be
>considered a blocker. But also they might not as they might have work
>arounds.


> A blocker is really something that we should decide on on a
>case by case basis, in my opinion.

Agree, especially at this stage of the release.

>
>On Wed, Jun 11, 2014 at 10:38 PM, Alena Prokharchyk
><Alena.Prokharchyk@citrix.com> wrote:
>> I guess its time to define what qualifies to be called a blocker bug. Is
>> blocker something that:
>>
>> 1) happens on all the setups?
>> 2) blocks core features from executing
>>
>> Because I think that the bug happening on KVM only (lets say the vms
>>fail
>> to start = core feature), can be considered as a blocker although it
>> happens just on a particular hypervisor/storage setup (niche
>>environment?)
>>
>> -Alena.
>>
>>
>> On 6/11/14, 12:53 PM, "Daan Hoogland" <daan.hoogland@gmail.com> wrote:
>>
>>>It is said by evil tongues in this mail thread that me, the RM does
>>>not nag enough about the 4.4 branch status and the bugs marked to
>>>apply to it. Worse; those evil tongues might just be right. In can
>>>hereby say without reservation and with full heart and soul that I
>>>will better my life in this perspect.
>>>
>>>With that of my chest I know that Hugo's mail was partially inspired
>>>on my nagging about the following: I don't care if cloudstack explodes
>>>and takes the earth and the moon down with it in its destruction, a
>>>bug is not a blocker unless we on this list decide that it blocks us
>>>from +1'ing a RC to be released. I do not say that critical issues
>>>aren't possible blockers but that should always be discussed. Also all
>>>this does not exempt us from triaging every bug down to trivial ones.
>>>As I discussed with my other colleague, Ian, the chance is real that a
>>>trivial bug is a blocker in someones niche environment with their
>>>niche use-case.
>>>
>>>In fact I think that no one should alter the default prio of any issue
>>>without discussing it on list.
>>>
>>>more nagging to follow,
>>>Daan
>>>
>>>On Wed, Jun 11, 2014 at 8:36 PM, Nitin Mehta <Nitin.Mehta@citrix.com>
>>>wrote:
>>>> But the blockers/criticals would keep coming unless its certified that
>>>>the
>>>> new features have been tested with some confidence and that the basic
>>>> functionalities work.
>>>>
>>>> Thanks,
>>>> -Nitin
>>>>
>>>> On 11/06/14 10:33 AM, "Mike Tutkowski" <mike.tutkowski@solidfire.com>
>>>> wrote:
>>>>
>>>>>According to that list, we have four blockers remaining...all network
>>>>>oriented.
>>>>>
>>>>>Murali Reddy has two. All four have an owner and presumably progress
>>>>>is
>>>>>being made.
>>>>>
>>>>>I guess it would be a good idea if we triaged critical defects and
>>>>>determined once the blockers are done if any of those should be fixed
>>>>>before an RC is built.
>>>>>
>>>>>
>>>>>On Wed, Jun 11, 2014 at 11:28 AM, Pierre-Luc Dion <pdion@cloudops.com>
>>>>>wrote:
>>>>>
>>>>>> Is there a list of issues, blockers, or todo items to be done in
>>>>>>order
>>>>>>to
>>>>>> have 4.4 out ?  The only things I saw is the list of blocker
>>>>>>currently
>>>>>> having 4 blocker (
>>>>>> 
>>>>>>https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112
>>>>>>)
>>>>>>
>>>>>> Does this mean that even if all blockers are fixed getting the
>>>>>>branch
>>>>>>4.4.0
>>>>>> able to build and be a workable CloudStack is a release manager
>>>>>>nightmare?
>>>>>>
>>>>>>
>>>>>> Pierre-Luc Dion
>>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>>>> 855-OK-CLOUD (855-652-5683) x1101
>>>>>> - - -
>>>>>>
>>>>>> *CloudOps*420 rue Guy
>>>>>> Montréal QC  H3J 1S6
>>>>>> www.cloudops.com
>>>>>> @CloudOps_
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 11, 2014 at 12:36 PM, Mike Tutkowski <
>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>
>>>>>> > Yeah, I am concerned about 4.4 getting farther behind schedule,
as
>>>>>>well,
>>>>>> > but I agree with David that we should not cancel it.
>>>>>> >
>>>>>> > I know it might be a pain, but I wonder if the RM would be willing
>>>>>>to
>>>>>> "nag"
>>>>>> > people every few days (just an e-mail to dev@) about the current
>>>>>>list
>>>>>>of
>>>>>> > blockers and their progress and to see if people need help and
>>>>>>others
>>>>>> might
>>>>>> > be willing and able to do so.
>>>>>> >
>>>>>> >
>>>>>> > On Wed, Jun 11, 2014 at 10:08 AM, David Nalley <david@gnsa.us>
>>>>>>wrote:
>>>>>> >
>>>>>> > > On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers
>>>>>><hugo@apache.org>
>>>>>> > wrote:
>>>>>> > > > Hey all,
>>>>>> > > >
>>>>>> > > > I¹m getting somewhat concerned about the 4.4 release.
We don¹t
>>>>>>seems
>>>>>> to
>>>>>> > > be able to get the 4.4 branch in shape for a release candidate
>>>>>>and
>>>>>> > > meanwhile master is diverging further and further. We also
know
>>>>>>that
>>>>>> once
>>>>>> > > we hit the RC phase we will probably need a sizable number
of
>>>>>> iterations
>>>>>> > to
>>>>>> > > eventually ship the release. Based on past experience,
if we
>>>>>>keep
>>>>>>up
>>>>>> like
>>>>>> > > this we will have another release that will actually be
released
>>>>>>way
>>>>>> > after
>>>>>> > > the feature freeze for the next release (July 18). Probably
>>>>>>leaving
>>>>>>us
>>>>>> in
>>>>>> > > the same bad spot for the next release.
>>>>>> > > >
>>>>>> > > > I tried to come up with a number of solutions that
could
>>>>>>rectify
>>>>>>the
>>>>>> > > situation and help the release move forward, but i can¹t
think
>>>>>>of
>>>>>>any.
>>>>>> > Save
>>>>>> > > for some options that might be considered extreme ideas.
One the
>>>>>>the
>>>>>> more
>>>>>> > > prominent ideas in my mind at the moment is skipping the
4.4
>>>>>>release
>>>>>> all
>>>>>> > > together and combine it with the next planned release (whether
>>>>>>its
>>>>>>5.0
>>>>>> or
>>>>>> > > 4.5). This would require a community effort to focus on
quality
>>>>>>in
>>>>>>the
>>>>>> > next
>>>>>> > > month and basically freeze the master for features and
have a
>>>>>>community
>>>>>> > > wide push for quality to get the next release out on schedule.
>>>>>> > > >
>>>>>> > > > But before i go on and shout out even more drastic
ideas, what
>>>>>>do
>>>>>>you
>>>>>> > > think about the current 4.4 release. How close do you feel
that
>>>>>>we
>>>>>>are
>>>>>> to
>>>>>> > > having a releasable product?
>>>>>> > > >
>>>>>> > >
>>>>>> > > So this sounds very familiar to a discussion we had in
4.1 or
>>>>>>4.2
>>>>>> > > timeframes. (I may have even been one of the folks proposing
>>>>>>similar
>>>>>> > > ideas, I don't recall)
>>>>>> > >
>>>>>> > > To save you some reading I am -1 on the idea of canceling
4.4.
>>>>>>(though
>>>>>> > > really - anyone can propose a release and ask for votes,
we have
>>>>>> > > adopted a bit more rigor, but that structure isn't demanded.)
>>>>>> > >
>>>>>> > > Here's the issues I see:
>>>>>> > > 1. We set the expectation that 4.4 is coming; people worked
hard
>>>>>>to
>>>>>> > > get features in, and our users are waiting on it.
>>>>>> > > 2. We may not be perfect from a schedule perspective, but
giving
>>>>>>up
>>>>>>on
>>>>>> > > a release is a pretty negative thing to do - whats the
reaction
>>>>>>going
>>>>>> > > to be?
>>>>>> > > 3. Do you think we are in a position to make 4.5 any better?
>>>>>>Speaking
>>>>>> > > very frankly, I worry that we are not. I don't think that
we
>>>>>>have
>>>>>> > > either the tooling or the social desire at present to make
>>>>>>significant
>>>>>> > > strides here. We don't dictate the priorities for individual
>>>>>> > > developers. It might be a different story if we were in
a
>>>>>>corporate
>>>>>> > > shop and could control what folks work on, it might be
a
>>>>>>different
>>>>>> > > story.
>>>>>> > >
>>>>>> > > --David
>>>>>> > >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > *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>*
*
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>*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>* *
>>>>
>>>
>>>
>>>
>>>--
>>>Daan
>>
>
>
>
>-- 
>Daan


Mime
View raw message