I'm not an ASF member, so I don't have access to the same information resources you do. I know there's a lot of areas where there's a great deal of latitude, but the page I was working through seems to be using some pretty strong language (ie, an entire "must" section, the only one on the page).
Just from a practical point of view, I can understand why the requirement is stated this way -- the release packages are the only static archived copies of the project. Revision control systems come and go, and are not immutable and sometimes old branches get corrupted -- I remember this happening in svn on the MyFaces project, leading to the inability to rebuild old versions. At minimum, I think we should be getting some clarification on the topic. Either the strong language in the master release faq should be changed, or we need to change our processes. I can only play by the rules/guidelines I know about. As a project, I think we should move toward having buildable source releases, even if we find that this is not currently a mandated requirement, but that would be a discussion for another time. On Mon, Aug 16, 2010 at 1:12 PM, Andrus Adamchik <[email protected]> wrote: > Hi Mike, > > There is a periodic discussion at various levels of Apache of how much > procedure is mandatory. As an ASF member, my firm belief (I think shared by > most in those discussions) is that release *packaging* is within the realm > of PMC responsibilities, if all *legal* requirements are otherwise met (to > me legal requirements are: no code without CLA coverage; NOTICE and LICENSE > files complete; 3 +1 votes from PMC). > > Case in point is recent iBatis meltdown. The community felt overly > constrained by the Apache release rules (not the only, but one of the main > gripes), so they decided to quit the ASF. When the Board and members heard > of it, there was a collective disbelief ("What release rules? Ain't PMC the > people who determine the rules?"). > > There are often well-intentioned attempts at various places (mainly > incubator) to formalize this or that process with the goal to provide > guidance to people, and those unfortunately end up appearing as "rules". But > ultimately there is nobody but ourselves (the Cayenne PMC) to determine what > goes in the tar.gz (with the exception of license related issues). With this > in mind I'll be happy to fix the NOTICE file, but the source build file is a > non-issue. > > Not trying to dismiss your concerns (and very happy that you actually took > the time to turn all the rocks looking at the distro), just giving my view > of things. Also if you think it is worth following up, let's find some > Foundation-wide avenue (infra? legal-discuss?) and move the discussion over > there. > > Cheers, > Andrus > > > On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote: >> >> On Mon, Aug 16, 2010 at 11:22 AM, Andrus Adamchik >> <[email protected]> wrote: >>>> >>>> Does the code build: cayenne-3.0.1.tar.gz -- I found no instructions >>>> on building the code from the source package we distribute. I don't >>>> see any build files either. >>> >>> No it doesn't, and it has never been the goal (ok, not since 1.0 when we >>> provided Ant buildfile). It is practically impossible to do that as the >>> build system is ... well, complex. I am sure most non-C Apache projects >>> won't let you build from sources in the distro. >> >> My understanding is that we are required to release source packages that >> build: >> >> http://www.apache.org/dev/release.html#what >> ========================================= >> What Must Every ASF Release Contain? >> >> Every ASF release must contain a source package, which must be >> sufficient for a user to build and test the release provided they have >> access to the appropriate platform and tools. The source package must >> be cryptographically signed by the Release Manager with a detached >> signature; and that package together with its signature must be tested >> prior to voting +1 for release. Folks who vote +1 for release may >> offer their own cryptographic signature to be concatenated with the >> detached signature file (at the Release Manager's discretion) prior to >> release. >> ========================================= >> >> Sorry to be the bearer of bad news, but if we haven't been doing this, >> then we are not releasing legitimate ASF releases. >> >> I know this is incredibly inconvenient and will probably require a >> great deal of work to fix, but if we're going to be an apache project, >> we have to follow the apache release rules. >> >> I have to vote -1. >> >> If I've somehow misinterpreted the release requirements, let me know. >> > >
