incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: freedom to do sane release management (was: Approve release Apache UIMA...)
Date Wed, 19 Dec 2007 17:43:27 GMT
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  
       distribution using a repeatable procedure with an acceptable  
       control system providing the master source, and both the  
       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  

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  
     in the files during checkout, and they get copied during the  

   built from tag, plus svn metadata
   * I generate my ChangeLog from `svn log --xml`, which is done by a  
     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  
     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  
     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
     (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.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message