On Wed, Mar 28, 2012 at 11:06 AM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > On Wed, Mar 28, 2012 at 1:16 AM, Leo Simons <m...@leosimons.com> wrote: >> That said, I'm not aware of us actually having such a release out there? > > Take such fringe projects like Ant, Tomcat, Lucene and Xalan that have > been shipping releases like throughout the past decade.
For the record, with "us" I meant "incubator"... > See examples > dating back at least to [1], [2], [3] and [4]. It looks like at least > Ant and Tomcat have since opted for downloading dependencies at build > time, but I must have missed the memo if that change was driven by > Apache policy requirements rather than just the emergence of the > central Maven repository making such downloads practical. I know 'something' about the ant example. If memory serves me well, alexandria, and from that gump, was originally created in part to help sort out the ant/tomcat/xerces build situation. There was at some point a pretty 'interesting' bootstrap+classpath problem because the xerces build used ant, ant used (sun) java, and java included xerces. Bootstrapping to a functional java is still hard today. The xerces that was shipped with ant from version 1.1 through to version 1.8.2 (released in 2010, 1.8.3 from 2012 is the first one that doesn't include a xerces implementation) has pretty clear provenance though, documented in a README alongside the jars: extracted from a named xerces binary release (which in turn is built from the xerces source release), and clearly apache licensed. Giving people a new xerces jar with ant was better than using a broken/old jdk xerces. So while that was ugly, and I'm glad we apparently finally are at a point now where the ant folks feel they don't need to ship xerces, by itself its not a particularly big threat to bootstrappability and code provenance and that kind of stuff, and the mess is further mitigated by also having a 'proper' bootstrap in the shape of gump for ant and xerces. It's a bit like downloading a binary version of libc and gcc to compile libc and gcc. I doubt many people bootstrap GCC, but at the same time I think a lot of people are aware it's possible, and a lot of people (linux kernel developers, for example) would be unhappy if it would somehow become impossible. I.e. if you look at http://www.opensource.org/docs/osd ... > 2. Source Code > The program must include source code, and must allow distribution > in source code as well as compiled form. Where some form of a > product is not distributed with source code, there must be a > well-publicized means of obtaining the source code for no more > than a reasonable reproduction cost preferably, downloading via > the Internet without charge. The source code must be the preferred > form in which a programmer would modify the program. Deliberately > obfuscated source code is not allowed. Intermediate forms such as > the output of a preprocessor or translator are not allowed." ...in the ant case there is a "well-publicized means of obtaining the source code" for those xerces jars. I guess there is some amount of judgement as to what is "well-publicized", what is "product", what is "distribution", and obviously what is "reasonable", and I can see how the role of apache policy would be to explain apache's judgement on the matter. Similarly to how apache obviously (is it obvious? not sure about this now?) chooses to have one standard "well-publicized means" of obtaining apache source code, namely "from tarballs downloaded from www.apache.org/dist/ or its mirrors". So I guess by some POV there's actually a sliding scale. I mentioned shipping a custom-ant-task.jar yesterday as something I could imagine. Next up, shipping ant.jar, so your users can compile without having ant installed, seems a little worse, but all in all it's still pretty obvious what's going on. I wouldn't be happy with it though. Shipping a set of CDDL jars out of some java.net projects that oracle has all but abandoned is far beyond my imagined threshold of reasonable on the scale. Do you actually see that differently? Figuring out which is which on the sliding scale you don't do by evaluating how you match against a policy, you do it by by applying the principle. Explaining how to do _that_ is probably going to prove surprisingly hard. > So to have anyone call this *not* a standard practice at ASF makes, to > borrow your expression, my jaw drop. And a board member who's > threatening to wipe out a decade worth of releases of some of the most > popular open source projects in the world. Again, to borrow your > expression, huh? I imagine Roy is making a point, not making a threat. The way we used to do this is move the files somewhere where 'normal' downstream users/developers wouldn't download them (like archive.apache.org). I think that can be a pretty healthy way to force action/change. At least, I imagine Roy doesn't mean to erase anything from archive.a.o! > As said earlier, I'm fine if people want to clarify our policies > regarding this and revise current practice. But let's please have a > proper debate about the merits of the alternatives and give affected > projects proper time to adjust in case changes are required. What is the alternative you're thinking of? Is it merely about the process by which we clean things up, or is there some other kind of more fundamental alternative? cheers, Leo --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
