Ewan: comments below. David: response to your point about OSCON conversations in another part of this thread is also below.
Generally, I'm sorry if I came off sounding like an alarmist. That wasn't my intent. I just don't want us to have an impedance missmatch between our "plan" and what's actually occurring. I'd also love to do everything in our power to avoid a complex discussion at the IPMC level for a release approval vote. The more we deal with up front, the less difficult that's going to be. On Wed, Aug 8, 2012 at 5:28 PM, Ewan Mellor <ewan.mel...@eu.citrix.com> wrote: >> -----Original Message----- >> From: Chip Childers [mailto:chip.child...@sungard.com] >> >> [Snip] >> >> So we're < 3 days away from the proposed release candidate being cut. > > No we're not. We're 3 days away from the proposed opening of the release > branch, when we would stop developing features, and switching into bug fix > mode. There's still another week between then and cutting the first release > candidate. Very good clarification, and my fault for not understanding the intent correctly. 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. > We have until the end of August to work on the test-bugfix-rebuild cycle, and > I'm sure that we can take build / licensing changes right up to the last > moment. Turning off and on features shouldn't have subtle effects -- it's > either all going to break or not -- so I'm much less concerned about those > kinds of changes compared with changes in the core of the code where things > can go subtly wrong and we need much more time for testing. This is the area of concern that caused me to ask the question about schedule... Complying with ASF guidelines / policies / licensing was our agreed upon focus for the release. Everything else was "nice to have" (and please don't take that as a statement of disinterest in all of the great new features being built!). To me, this translates into the licensing work being the critical path for us to release. We agreed to be time-bound, but I think that these issues are in a different category than a feature. It's become increasingly clear that the IPMC wants licensing to be *mostly* cleaned up prior to a Podling being allowed to cut an official ASF release of the software. By *mostly*, it appears that a few missed headers aren't going to block us. So to summarize my opinion here: - 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. We may very well make it by the 17th, making my issue here moot... ;-) > Now, whether we're going to make the feature-complete deadline is a good > question. It looks like the VPC and autoscale branches aren't going to land > before Friday, and Jamshid (Caringo)'s patch needs a push over the line too. > So we may still be too close to the wire, assuming that we want these > features in 4.0 given that the code is right in front of us already. We've defined a process to get stuff included, and we've also agreed to be time-bound for inclusion in a release. So based on that, I guess we'll only include the features that are able to make it through the process before the release branch is created. > I personally don't think that the binary-licensing issues are a blocker for > release. The official release is a source code release. Anything that we do > in terms of binaries is just for convenience for people. Now, I would > definitely be unhappy if we can't ship binaries that are useful, but from a > legal point of view I don't think that it's an issue. If the Foundation > denies our request to distribute them, then users will have to do without, > but we can still ship the code. It would mean the installation instructions > get longer and more complicated, but other than that things should still work. > > It's possible that Citrix (or anyone else) could host binaries compiled from > official Apache source. That would be disappointing, but it might help us > bridge the gap without completely inconveniencing our users. 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. :-) 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? Ewan, to your point, I think the community will have to find an alternative location for the system VMs outside of ASF infrastructure. That, or just simply not change where the actual code expects to find them for download... i.e.: downloads.cloud.com. (with Citrix agreement obviously!) [1] - http://www.apache.org/legal/3party.html#options-distribution -chip
