cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS] Release 4.4
Date Wed, 11 Jun 2014 19:53:36 GMT
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

Mime
View raw message