Hi Jeremias,
Jeremias Maerki wrote:
On 18.03.2005 17:24:35 Thomas DeWeese wrote:
For those that are following the Batik lists you probably know that I am getting near to making a release.
Means that you'd rather not wait for the code reorganization (SVN, Commons etc.), right? It's ok if you want to do that, I just want to be clear what we're talking about.
The reorg is one of the main reasons I want to do the release now. If it doesn't go out soon it will likely be delayed as well as having to deal with new issues creeping in due to the refactoring. Not to mention Cameron has a bunch of code hanging out on a branch that I would like to land on head as soon as possible so we don't permanently fork the code base.
The first part of this question is can I produce a release candidate with "low overhead"? (i.e. whenever the mood strikes me ;). Note that this would not go in the mirrored distribution directory but into the cvs 'builds' directory where Batik currently places nightly dumps of CVS.
Would you announce such a release candidate on the lists?
You mean like is done for every CVS commit? Yes. I would announce that a release candidate is available for testing in the 'builds' directory.
If yes, I'd still consider it a release as such which the PMC would have to vote on, because people will use it.
I don't see the large distinction, people use CVS but we don't have a PMC vote every time a commit is done. It doesn't go out to mirrors and it lives exactly where a copy of current CVS is dumped every night. The only real difference is that I will have run 'build dist-zip' for them, ok it will be a little more since I will be laying down a tag etc. but I don't think people will easily confuse it with a true release.
I think it would be unfortunate if there was not a mechanism in place for producing something between a CVS snapshot and a full on release.
Then second what is the process for doing a full release?
A release has to be santioned by the PMC, because it's the PMC that acts
as an established entity of the ASF. The PMC is responsible for any
release. That's why it's its duty to make sure that any serious issues (like IP concerns) are dealt with and that it's the (sub-)project
community's general will that a release happens.
I've followed the things that happened inside Batik and there are two items that I need to bring up:
- I haven't seen any discussion on the point in time that a release
should take please. All active committers should consent to a release (even a release candidate).
Cameron (really the only other active committer) and I have discussed the desire/need for a release. Part of the purpose of this note was to find out what needed to be done so I could summarize a path forward to a release to the wider Batik mail list (although I have often hinted that I am interested in making a release).
- As the PDF/PS transcoders are not transferred, yet, you either have to exclude pdftranscoder.jar from the release or involve the FOP team so they at least tag the CVS and so they have a chance to speak up if there are any issues around that need to be adressed prior to a release (I don't think there are any right now, that part is stable. I'm just outlining the process as I see it.).
Yes, I agree that getting FOP to tag the code used by the Batik release would be very good. In fact ideally, we would have a tag for every pdf-transcoder.jar I incorporated into Batik (although this may be being a bit pedantic).
In the past FOP released with CVS snapshots of third-party libraries. I think that was bad and that's why I wrote the above. And I will block any such action in the future, because we need to make sure that a release is sound and that no hidden issues (that we have a chance to find out) remain.
Isn't this part of the purpose of a release candidate? I view a release candidate as a step on the road to a full release. It offers an easier way for 3rd parties to pick up the current work and test for unexpected problems.
I understand that the above presents additional work but I consider this part of the overseeing process that the Board wanted to reestablish.
No this is all good. I agree that this is exactly what the PMC should be doing.
I just think that we can quite clearly and easily draw a line between code that is made available on 'cvs.apache.org/builds' (Development/Testing) vs code that is made available on 'www.apache.org/dist' (Release/Production).
In fact if you read: http://www.apache.org/dev/release.html#releases
I think it supports my position on this. Also the "Which Directory for What" section.
--------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
