On Feb 1, 2006, at 11:04 AM, Mark Womack wrote:
I'm pretty sure that I did not update to the latest site contents
before doing the a8 build. Oversight on my part. If that makes a
concrete difference, then we should -1 and do it again.
(Have I mentioned that I really dislike having a dependency on a
separate repo?)
log4j no longer depends on the "logging-site" module. However the
content on http://logging.apache.org/log4j is generated from the
files in src/xdocs.
-Mark
On 2/1/06, Mark Womack <[EMAIL PROTECTED]> wrote:
Not sure what you are looking at to determine ant version. If I look
at the jar files in the dist image, the manifest clearly says it was
built with ant 1.6.5.
My bad. My comparison build was done with Ant 1.6.4 and I
misinterpreted the diff output.
I re-copied the alpha8 tag after applying all of the latest build/
test
related changes in the log4j repo.
I did not see a SVN commit message and the contents and log for
http://svn.apache.org/repos/asf/logging/log4j/tags/v1.3alpha8/
build.xml do not indicate that the "breakiterator" change and the
restoration of the DLL build.
svn log http://svn.apache.org/repos/asf/logging/log4j/tags/v1.3alpha8/
build.xml
svn diff http://svn.apache.org/repos/asf/logging/log4j/tags/
v1.3alpha8/build.xml http://svn.apache.org/repos/asf/logging/log4j/
trunk/build.xml
I have not applied any changes or
tags to the site repo, so I am guessing that is what you are talking
about here. I can make a tag (somehow as you describe).
Not what I was talking about.
There will
be another tag in site for the actual changes for the 1.3a8 dist
release (updating download.xml, other 1.3a8 info, etc).
I'm uncomfortable with changes occurring after voting. My preference
would be that the checksum of the tarballs and zips not change
between the call for a vote and placing the release on the
distribution servers. One of the things that I check when there is a
call for a vote is that I am able to reproduce the build (other than
expected differences like timestamps), hopefully to prevent the build
from being dependent on something on the build machine and to
increase the odds that we can make maintenance releases. Making
changes after preparation of the release candidate invalidates the
effort and that has to be done yet again and with little recourse if
some problem slipped in.
The release policy for httpd (http://httpd.apache.org/dev/
release.html) may be instructive, however they use the terms alpha
and beta in different manner where alpha we might call release
candidate.
No changes can be made between alpha, beta, and GA status. The only
difference is the file name that is downloaded by the users.
I do not see any reason in the current bylaws that the log4j-dev vote
and the pmc vote can not be concurrent. I do think that releases
need to be approved by the PMC, but it should not have to add any
time. Just post the call for vote on both lists.
In this case, I would suggest:
1. Copy the contents of log4j/trunk to log4j/tags/v1.3alpha8
2. Update the contents of log4j/trunk/src/xdocs/download.xml and
other files to reflect pending release of log4j 1.3alpha8
3. Announce the results of the vote
4. Prepare signatures for the tarball and zip currently on
cvs.apache.org
5. Copy existing tarball and zip to dist server.
6. Update http://logging.apache.org/log4j
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
