Mailing-List: contact general-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xmlgraphics.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Fri, 18 Mar 2005 22:40:17 +0100
From: Jeremias Maerki <dev.jeremias@greenmail.ch>
To: general@xmlgraphics.apache.org
Subject: Re: Batik Release Process?
In-Reply-To: <423B4604.9050304@Kodak.com>
References: <20050318195907.C2BA.DEV.JEREMIAS@greenmail.ch>
 <423B4604.9050304@Kodak.com>
Message-Id: <20050318223035.C2C3.DEV.JEREMIAS@greenmail.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit


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