xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: Batik Release Process?
Date Fri, 18 Mar 2005 19:15:40 GMT

On 18.03.2005 19:35:08 Thomas DeWeese wrote:
> 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.

That's what I figured.

> >>    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.

You'd be surprised how many people still use FOP release candidates
today and the last (final) release is almost two years ago.

>     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).

I understand. Still, I'd prefer a formal vote for the records which more
or less fixes the point in time where there release should take place.

> > - 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).

No, I wouldn't consider that pedantic. Well, maybe I am. :-)

> > 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.

No, a release candidate is about stabilizing (technically!) a piece of
software. You expect people to download the release candidate and try it
under more serious conditions. And for that end, I believe the ASF
expects that such releases are free of IP and licensing issues and that
a release represent the general consent of the developing community.
That's why they list a release candidate under "releases" (see below).

> > 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.

Actually, I read that page exactly the other way round. It says that
releases all have some measure of official approval and lists release
candidates under unstable releases. If you look through
http://cvs.apache.org/builds you will see that Batik is the only project
that has files in there that are not nightly builds. So I think you're
bending the rules a bit here. :-)

Jeremias Maerki

Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message