xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: Batik Release Process?
Date Fri, 18 Mar 2005 18:35:08 GMT
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: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message