> 
> On Mon, Sep 9, 2013 at 3:01 PM, Sebastien Goasguen <run...@gmail.com>
> wrote:
> > Maybe before we get to carried away talking about future releases and
> more automated testing (which is great and many of us have advocating
> for and Prasanna has done outstanding working on BVT, jenkins and the
> test matrix), we need to focus on how to get 4.2 out.
> >
> > Marcus has a binding -1, so that means the vote fails and we need
> another RC (unless someone challenges Marcus's veto and he changes his
> mind).
> >
[Animesh>] Sebastien the VOTE is by majority not a VETO. 

> > So what needs to be in the RC (aside from the cherry pick mentioned by
> Marcus).
> > Are there more blockers ?
> > Do we need to invest in more testing before cutting that new RC or is
> it just that one cherry pick ?
> >
> > If we agree on that and test before cutting, then maybe the vote can
> > pass :)
> >
> > -sebastien
> >
> >
> > On Sep 9, 2013, at 4:47 PM, Daan Hoogland <daan.hoogl...@gmail.com>
> wrote:
> >
> >> Why can't we cover every use case, Marcus. We will need help from
> >> users, but if they do help it will be easy to do so.
> >>
> >> On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen
> <shadow...@gmail.com> wrote:
> >>> I was actually talking about separate things in relation to this
> >>> thread and the other where I mentioned that I'd like to see a
> >>> release focused on bugfixing and testing. With that, I'm advocating
> >>> a test for every api call and focusing on broadening use case test
> coverage.
> >>>
> >>> Here, I'm simply talking about taking the support matrix and doing
> >>> some vary basic testing. This can be a dozen or so tests, each
> >>> platform we say we support needs to successfully deploy a zone and a
> >>> vm on every storage type that is in the support matrix. I don't
> >>> think this would include plugins (or maybe those are left to the
> >>> developer of the third party plugin). For KVM, this is literally a
> >>> marvin script away from being there, I don't think there's a ton of
> >>> work. I have no idea what we have or can do with vmware, and I'm
> >>> guessing Xen is largely covered already.
> >>>
> >>> We'll never be able to cover every use case, I may be able to deploy
> >>> a zone with my KVM setup, but not someone else's special network
> layout.
> >>> I'd just like to see sanity checks to say it works, at all, on the
> >>> handful of 'supported' systems.
> >>>
> >>> On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski
> >>> <mike.tutkow...@solidfire.com> wrote:
> >>>> Do we have any statistics that say how many of our customers are
> >>>> using feature x, feature y, etc.?
> >>>>
> >>>> If not, I would say if we know about a feature that has regressed
> >>>> to the point of breakage in 4.2 that it should be fixed before
> >>>> releasing (or at the very least well documented, so - if it is
> >>>> impactful to someone - they do not upgrade until it has been
> fixed).
> >>>>
> >>>>
> >>>> On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
> >>>> chiradeep.vit...@citrix.com> wrote:
> >>>>
> >>>>> I think that Animesh is trying to stress what is "key". If it hits
> >>>>> 1% of cloud operators is it key?
> >>>>>
> >>>>>
> >>>>> On 9/9/13 7:42 AM, "Simon Weller" <swel...@ena.com> wrote:
> >>>>>
> >>>>>> -1 from me as well.
> >>>>>>
> >>>>>>
> >>>>>> I know we're trying to hit timed releases, but I think it's very
> >>>>>> important to preserve key underlying functionality across
> >>>>>> releases. If a supported and documented feature is known to be
> >>>>>> broken, we need to address it...if we don't, it's going to cause
> >>>>>> lots of pain, and reflect badly on ACS as a project.
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>
> >>>>>> From: "Chip Childers" <chip.child...@sungard.com>
> >>>>>> To: dev@cloudstack.apache.org
> >>>>>> Sent: Monday, September 9, 2013 9:24:23 AM
> >>>>>> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> >>>>>>
> >>>>>> On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
> >>>>>>> -1 ... sorry guys, especially with Simon chiming in.
> >>>>>>>
> >>>>>>> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-
> picked.
> >>>>>>
> >>>>>> Agreed.
> >>>>>>
> >>>>>> I'm -1, given simon's perspective as well. Since we have the fix,
> >>>>>> let's get it into the release.
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> *Mike Tutkowski*
> >>>> *Senior CloudStack Developer, SolidFire Inc.*
> >>>> e: mike.tutkow...@solidfire.com
> >>>> o: 303.746.7302
> >>>> Advancing the way the world uses the
> >>>> cloud<http://solidfire.com/solution/overview/?video=play>
> >>>> *(tm)*
> >

Reply via email to