[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: To RC1 or not to RC1?

From: Kobayashi Noritada <nori1_at_dolphin.c.u-tokyo.ac.jp>
Date: 2006-07-02 02:15:14 CEST

Hi,

> The question now is: do we want to release RC1 ?
>
> The issues: several bugs were found during testing. Some turned out to
> be "the bdb fixes", addressing some problems with our handling of bdb
> 4.4. Branko started work on the fixes, and has to my knowledge
> commited some. There is one tricky bug left, which rooneg has a lead
> on.
>
> (snip)
>
> So, do we scrap and wait for the last of the fixes and backports for
> RC2, or release RC1, fully knowing that it is obsolete before release?

It is better to roll RC2 soon and try to make it public than to release RC1.
Although containing a known unresolved issue, RC2 will have less bugs and
most of known grave problems in RC1 will already have been resolved in RC2,
which is important. When some unresolved grave bugs are fixed before
releasing RC2, we should abort it and try to make RC3 public. IMO one of
the aims of public RCs is to check whether the program has other unknown
issue and, in order to avoid making the total stabilizing period longer,
which may make developers disinterested in the release process, we should
not postpone RCs to a day all the bugs are fixed.

We should make a period from rolling a tarball to making it public as
short as possible. Otherwise danderson cannot release RCs without anxiety
since they can get outdated soon in the early stages of stabilization. :-)

Just an opinion of a partial committer who does not have right to add sigs. ;-)

Thanks,

-nori

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 2 02:15:45 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.