On Dec 18, 2007, at 11:50 PM, William A. Rowe, Jr. wrote: > Noel J. Bergman wrote: >> I disagree. I agree with the statement that "All releases should >> be built >> from a tag." Worst case, you should make the tag by copying from >> the right >> version. That'd be a different rule; it's a tiny bit less broken a rule. Bill initially said "Your distribution must correspond to subversion", specifically objecting to a scenario where the distribution was in fact generated from a subversion tag, but a bit differently structured. It's still a bad rule, because you're taking a (questionable) version control convention and making a rule out of it. The rules you're looking for are something like All source code in a source distribution should arrive in that source distribution using a repeatable procedure with an acceptable source control system providing the master source, and both the repeatable procedure and source control itself must be auditable. SVN is an acceptable source control system. Creating a straighforward tarball directly from an svn export is acceptable as a repeatable release-building procedure, though the expectation is that this is automated using a script. > The bottom line of release management in the ASF. > > > All artifacts should be generated from the tagged SVN < That just isn't the bottom line. It's only the bottom line in some projects. It isn't ASF-wide policy, and if it were policy, it would not be a good policy, and would also not be enforceable. Just a few use cases that invalidate such a potential rule: built from tag, plus svn:externals * I have many subprojects that need the same license files. I put the license files in a central place, and then use svn:externals to pull in the files during checkout, and they get copied during the tarball build built from tag, plus svn metadata * I generate my ChangeLog from `svn log --xml`, which is done by a the same script that produces the tarball. The ChangeLog itself never makes it into SVN as its derivative of svn data itself. built from tag, plus non-tag svn metadata * I generate my ChangeLog directly from my branch because '--stop-on-copy' will do the right thing built from tag, plus additional files from other information system * I fetch documentation directly from our wiki installation for inclusion into every source distribution. I don't want to put the 40 megabytes of documentation into SVN. documentation distribution * my project is a CMS. We eat our own dogfood and maintain all our documentation inside an instance of our own CMS. I fetch documentation directly from that CMS and generate a documentation distribution out of it, thus showcasing how great my CMS is every time I do a release. my project does not use tags * I understand how subversion works internally, think that the trunk/branches/tags structure is a silly convention which does not make sense to use for my project because we have historically been supportive of the development mode used for distributed VC, so we have a lot of branches and a lot of semi-independent tips my project doesn't like unresolveable URLs * I fetch the LICENSE at build-time from http://www.apache.org/licenses/LICENSE-2.0 (yes, of course I program defensively and ensure a 200 return code and check the content of the file is roughly what I expected) You can obviously argue against any particular one of these and invent "what ifs" that, unless addressed, make it a bad idea to do things that way. They're just examples. The point is that, on the whole, there are many many ways to do really good and really dilligent release management, including doing very good tracking of everything in version control, yet still do a lot of things very differently. The second point is that there's a frequent tendency among incubator PMC members (and, err, most other human beings) to take their own opinions and experience about what constitutes reasonable practice and turn that into policy, taking away key elements such as self- governance in the process. This is just the one example. Do everyone a favor, work a little harder, and find the *real* thing we need to see ensured, independently of your own habits or preferences. The third point is that making sweeping statements about what must and must not happen probably does not help anyone, not when you do it off-the-cuff, without having some reference to any documentation or e- mail thread or whatever to back up the statement. And especially note when you swept a little too far. ciao! /LSD --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org