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