Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 68DA8DC82 for ; Fri, 10 Aug 2012 08:20:27 +0000 (UTC) Received: (qmail 90621 invoked by uid 500); 10 Aug 2012 08:20:27 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 90481 invoked by uid 500); 10 Aug 2012 08:20:27 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 90471 invoked by uid 99); 10 Aug 2012 08:20:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2012 08:20:27 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [109.72.87.138] (HELO smtp02.mail.pcextreme.nl) (109.72.87.138) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2012 08:20:19 +0000 Received: from [IPv6:2a00:f10:113:0:d596:e4b6:fc4f:4836] (unknown [IPv6:2a00:f10:113:0:d596:e4b6:fc4f:4836]) by smtp02.mail.pcextreme.nl (Postfix) with ESMTPSA id 6E93E40316 for ; Fri, 10 Aug 2012 10:19:58 +0200 (CEST) Message-ID: <5024C42F.2040301@widodh.nl> Date: Fri, 10 Aug 2012 10:19:59 +0200 From: Wido den Hollander User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: cloudstack-dev@incubator.apache.org Subject: Re: [ASFCS40] CloudStack 4.0 release plan References: <6005BE083BF501439A84DC3523BAC82DE44D7E3B74@LONPMAILBOX01.citrite.net> <6005BE083BF501439A84DC3523BAC82DE44D7E41E0@LONPMAILBOX01.citrite.net> <6005BE083BF501439A84DC3523BAC82DE44D7E42EC@LONPMAILBOX01.citrite.net> In-Reply-To: <6005BE083BF501439A84DC3523BAC82DE44D7E42EC@LONPMAILBOX01.citrite.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/10/2012 02:27 AM, Ewan Mellor wrote: >> -----Original Message----- >> From: Chip Childers [mailto:chip.childers@sungard.com] >> >> [Snip] >> >> Thinking about the milestone along those lines, I agree that cutting a >> release branch over the weekend is a good thing. This is specifically >> because of the pending review board submissions that we should start >> getting integrated into master as a parallel activity to 4.0 work. > > OK, so I think from this and David's earlier email and general consensus that we want to get into a time-based schedule, then we're still on to start the feature freeze at the end of Friday, and have a 4.0 release branch ready for Monday morning. Everyone agreed? +1, from monday on we'll have a 4.0 branch. That means however that you have to submit bugs fixes into master and 4.0.x, right? > >> [Snip] >> >> - Regardless of our desire to be time-bound for our releases, our >> first release has a higher-order issue (licensing) that will block us >> if anything significant is outstanding. >> - Given the importance of the licensing aspects, I believe that we >> have to think of the "First release candidate build" milestone as >> being predicated on the community believing / agreeing that we have >> achieved a satisfactory level of compliance to pass an IPMC vote. > > Yes, makes sense to me. > >> [Snip] >> >> Let's think about "convenience builds" along two lines (because there >> are different issues to deal with): >> >> Binary distribution of the core project - I think this is basically >> sorting through the optional vs. required components. Any binary >> distro we produce would be only include the required build targets, >> not the optional ones. I'm not sure there is much debate open here. >> We're headed down the right path. :-) > > Yep. > >> System VMs - I've reviewed the discussion notes from OSCON again, just >> to refresh my memory. I might not be understanding the verbal >> conversation correctly, but it doesn't seem to match what I see on the >> apache.org/legal site. Specifically, David mentioned that there was >> verbal consensus that we could possibly "prepare a system VM as we >> distribute it now as a convenience binary". The item that I'm >> concerned about is the "Distribution" section of the Third-Party >> Licensing Policy [1] that says "YOU MUST NOT distribute a prohibited >> work from an apache.org server.". Doesn't the system VM qualify as a >> prohibited work? > > I agree that System VM binaries are forbidden by written policy. It is possible to ask for exceptions to this policy -- I have done so for libvirt-java, and Sam Ruby says that he'll approve that next week if no-one disagrees in the meantime. If we felt that we needed to make a similar request regarding System VMs, we can do that. > > Getting alternative infrastructure is a possibility. I'm sure Citrix could manage that, though I worry about the perception that would create, if the software is effectively unusable without Citrix servers. > > Cheers, > > Ewan. > >