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: [DISCUSS] Release 4.4
Date Wed, 11 Jun 2014 21:23:45 GMT
Sounds reasonable

That being the case, do we feel we can build a first RC once our remaining
blockers are completed?


On Wed, Jun 11, 2014 at 3:19 PM, Daan Hoogland <daan.hoogland@gmail.com>
wrote:

> Well, I think we should always treat the status of blocker that way.
> Something is a blocker if we feel it blocks us from releasing. Not
> just in this stage but always. (I think I am repeating myself a tad)
> In fact I feel we must treat those 90 critical issues the same way and
> I dare not start to think about all the other bugs of lower prios.
>
> On Wed, Jun 11, 2014 at 11:11 PM, Mike Tutkowski
> <mike.tutkowski@solidfire.com> wrote:
> > I agree - at this stage in the release, each blocker that remains should
> be
> > decided on a case-by-case basis if we still feel it is a blocker.
> >
> >
> > On Wed, Jun 11, 2014 at 2:54 PM, Alena Prokharchyk <
> > Alena.Prokharchyk@citrix.com> wrote:
> >
> >>
> >>
> >> 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
> >>
> >>
> >
> >
> > --
> > *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
>



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