You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Thomas DeWeese <Th...@Kodak.com> on 2005/03/18 19:35:08 UTC
Re: Batik Release Process?
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
Re: Batik Release Process?
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 18.03.2005 22:20:04 Thomas DeWeese wrote:
> > On 18.03.2005 19:35:08 Thomas DeWeese wrote:
>
> >> 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.
>
> Jeremias Maerki wrote:
>
> > 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.
>
> I missed the reference to "release candidates". I agree they need
> to be considered a release :(.
>
> The problem is that this just pushes you to skip the 'rc'.
> I was hoping to quickly get an RC out for people to test with
> while the processes rolls along for the real release.
Taking my PMC chair hat off, you could simply tell the user community
that Batik is nearing a release and that interested people can have a
look at one of the nightly builds (with the usual disclaimers) until you
have the release candidate ready. Hat on again. :-)
> Now that I can't do that I'll probably just resign myself
> to the formal release (I really don't think anything is unstable
> I just wanted to give that extra % or two a chance to check it
> out ahead of time, plus giving me a chance to practice a full
> build again).
>
> Anyway, what's the check-list?
>
> 1) a) Vote on batik-dev for a release.
> b) Vote(?) on fop-dev for tagging PDF code
> 2) Vote on xmlgraphics-pmc for release.
> 3) Make release?
Yes, that's it. I think 1b) is really pro-forma, because there haven't
been any big changes lately in the code involved and I know the code is
free of any IP issues and works fine.
>
> >>> 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.
>
> I never anticipated skipping the formal vote, I just wanted to
> have my ducks in a row before starting the formal vote. For example
> I would have mentioned putting out a release candidate which it
> looks like won't happen now.
As I tried to outline, you need to look at two different things. It's
the procedures part (where the votes are necessary) and there's the part
about stabilizing the codebase by providing a release candidate to your
users. The final release after the RC phase will be done quickly, since
you can reuse the tag you get from the FOP vote. And you will have
everything set up again and working. I'd still consider doing an RC, but
that's up to you.
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
Re: Batik Release Process?
Posted by Jeremias Maerki <de...@greenmail.ch>.
I guess the problem is that some people are not really into downloading
code from CVS even if they can through the corporate firewall.
On 18.03.2005 22:32:50 The Web Maestro wrote:
> Couldn't you just do a tag like pre-release_candidate or something, so
> that people can have a reference for testing? It wouldn't be added to
> the www.apache.org/dist/ list, and would be similar to a snapshot,
> however, it would fill the purpose of having everyone test the same
> release^H^H^H^H^H^H tagged snapshot.
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
Re: Batik Release Process?
Posted by The Web Maestro <th...@gmail.com>.
On Mar 18, 2005, at 1:20 PM, Thomas DeWeese wrote:
>> On 18.03.2005 19:35:08 Thomas DeWeese wrote:
>>> 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.
>
> Jeremias Maerki wrote:
>> 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.
>
> I missed the reference to "release candidates". I agree they need
> to be considered a release :(.
>
> The problem is that this just pushes you to skip the 'rc'.
> I was hoping to quickly get an RC out for people to test with
> while the processes rolls along for the real release.
Couldn't you just do a tag like pre-release_candidate or something, so
that people can have a reference for testing? It wouldn't be added to
the www.apache.org/dist/ list, and would be similar to a snapshot,
however, it would fill the purpose of having everyone test the same
release^H^H^H^H^H^H tagged snapshot.
Web Maestro Clay
--
<th...@gmail.com> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
---------------------------------------------------------------------
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
Re: Batik Release Process?
Posted by Thomas DeWeese <Th...@Kodak.com>.
> On 18.03.2005 19:35:08 Thomas DeWeese wrote:
>> 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.
Jeremias Maerki wrote:
> 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.
I missed the reference to "release candidates". I agree they need
to be considered a release :(.
The problem is that this just pushes you to skip the 'rc'.
I was hoping to quickly get an RC out for people to test with
while the processes rolls along for the real release.
Now that I can't do that I'll probably just resign myself
to the formal release (I really don't think anything is unstable
I just wanted to give that extra % or two a chance to check it
out ahead of time, plus giving me a chance to practice a full
build again).
Anyway, what's the check-list?
1) a) Vote on batik-dev for a release.
b) Vote(?) on fop-dev for tagging PDF code
2) Vote on xmlgraphics-pmc for release.
3) Make 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.
I never anticipated skipping the formal vote, I just wanted to
have my ducks in a row before starting the formal vote. For example
I would have mentioned putting out a release candidate which it
looks like won't happen now.
---------------------------------------------------------------------
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
Re: Batik Release Process?
Posted by Jeremias Maerki <de...@greenmail.ch>.
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