On Mar 28, 2012, at 11:06 AM, Jukka Zitting 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. 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. > > 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 consider them to be trojan horses. I wouldn't hesitate for a second to delete them outright. Actually, what I've done in the past (yes, I have done this before) is move them to a subdir of my homedir and then tell the relevant project to WTFU and do it right. Note, however, I would not delete the ones in archive -- that would be silly. > 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. > > [1] http://archive.apache.org/dist/ant/source/jakarta-ant-1.1.zip > [2] > http://archive.apache.org/dist/tomcat/tomcat-3/src/jakarta-tomcat-3.3.1a-src.tar.gz > [3] http://archive.apache.org/dist/lucene/java/archive/lucene-1.4.3-src.tar.gz > [4] http://archive.apache.org/dist/xml/xalan-j/source/xalan-j_2_2-src.tar.gz Yeah, but I don't see why you think this is open to debate. It isn't. I can't keep track of what every project includes in every source release -- that's why this is delegated to PMCs. I expect them to understand the basic principles by which Apache exists. When they failed to understand, we created the Incubator to ensure this failure doesn't happen again. No, it's not my sole responsibility to ensure that this is documented correctly -- that was a directive given to the Incubator when it was created. Now I am being told that incubator teaches FAILURE because they've seen it in the past? Me not happy. This is not any individual's fault, least of all Jukka, and certainly not a fault of the ManifoldCF podling that is going through this fun precisely to learn how to create an Apache release. It is an institutional fault. We need to separate our policy docs into example procedures and basic principles. The former are ways to do things right that can be improved upon over time. The latter are requirements established by the membership of the ASF, enshrined in our corporate mission, and enforced by the board of directors. ....Roy --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
