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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
