Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0A67A10E7E for ; Wed, 11 Jun 2014 20:55:52 +0000 (UTC) Received: (qmail 66469 invoked by uid 500); 11 Jun 2014 20:55:51 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 66418 invoked by uid 500); 11 Jun 2014 20:55:50 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 66408 invoked by uid 99); 11 Jun 2014 20:55:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Jun 2014 20:55:50 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Alena.Prokharchyk@citrix.com designates 66.165.176.89 as permitted sender) Received: from [66.165.176.89] (HELO SMTP.CITRIX.COM) (66.165.176.89) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Jun 2014 20:55:46 +0000 X-IronPort-AV: E=Sophos;i="5.01,460,1400025600"; d="scan'208";a="142670833" Received: from sjcpex01cl01.citrite.net ([10.216.14.143]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 11 Jun 2014 20:54:56 +0000 Received: from SJCPEX01CL02.citrite.net ([169.254.2.117]) by SJCPEX01CL01.citrite.net ([10.216.14.143]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 13:54:55 -0700 From: Alena Prokharchyk To: "dev@cloudstack.apache.org" Subject: Re: [DISCUSS] Release 4.4 Thread-Topic: [DISCUSS] Release 4.4 Thread-Index: AQHPhYowPYlLv3VDPki9ut0eqHJxQ5tsiQ+AgAAH5wCAAA5wAIAAAX6AgAARdICAABWWAP//lxyAgAB3gAD//400gA== Date: Wed, 11 Jun 2014 20:54:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.214.4.78] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org On 6/11/14, 1:45 PM, "Daan Hoogland" 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 > 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 =3D 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" 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 >>>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" >>>> 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 >>>>>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 ( >>>>>>=20 >>>>>>https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=3D123271= 12 >>>>>>) >>>>>> >>>>>> 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=E9al 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 >>>>>>wrote: >>>>>> > >>>>>> > > On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers >>>>>> >>>>>> > wrote: >>>>>> > > > Hey all, >>>>>> > > > >>>>>> > > > I=B9m getting somewhat concerned about the 4.4 release. We don= =B9t >>>>>>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=B9t 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 >>>>>> > * * >>>>>> > >>>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>>*Mike Tutkowski* >>>>>*Senior CloudStack Developer, SolidFire Inc.* >>>>>e: mike.tutkowski@solidfire.com >>>>>o: 303.746.7302 >>>>>Advancing the way the world uses the cloud >>>>>* * >>>> >>> >>> >>> >>>-- >>>Daan >> > > > >--=20 >Daan