cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Vote withdrawal (was Re: [VOTE] preservation policy for third-party snapshot sources)
Date Tue, 29 Jun 2004 09:01:26 GMT
David Crossley wrote:

>Sylvain Wallez wrote:
>>Please cast your votes:
>[+1] do not keep sources
>and use a full timestamp (as UTC time) in the jar filename
>so that people can get the sources from the relevant
>external CVS, e.g. foobar-20040628T0824.jar

Considering that everybody has strong arguments either for or against 
source inclusion, it seems we'll never be able to reach a consensus on 
this source preservation problem by including *some* of the sources in 
our CVS repo, either as part of the jars, either as separate zip files.

What is annoying me is that some people don't seem to have understood 
the value of this, which is to be able to easily track bugs into Cocoon 
in the transient state that separates official releases. Anyway...

I therefore withdraw the vote and consider David's proposal above a good 
mid-term solution that better helps to find the sources than a simple 
date timestamp.

However, we have to clearly define how this timestamp should be 
produced: *it cannot be the build time*, as the source repository may 
have changed between the checkout and the build.

So having this minute-precise timestamp means that:
- your computer is synchronized to an NTP server on the Internet,
- when checking out the CVS, you use "cvs update; date -u +%Y%m%dT%H%M" 
(what's the non-cygwin windoze equivalent?) to have the precise 
_checkout_ time in UTC.
- you make no modification on the source files after this update.

If you're a committer on the 3rd party library, the "cvs update; date" 
should be done again after any commit to take into account any other 
changes that other people may have made since your last update.

Does this sound better? Can we reach a consensus here?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message