On Sun, 08 Aug 2004 05:02:09 +0800
John Summerfield <debian@ComputerDatasafe.com.au> wrote:
Chris Metzler wrote:
On Sat, 07 Aug 2004 21:04:31 +0800
John Summerfield <debian@ComputerDatasafe.com.au> wrote:
How do you justify that pov? At present, we have more platforms than
ever before, more packages than every before. What's changed to
alleviate the log cycle time we've had so far?
Why is the number of packages relevant? It certainly wasn't for this
Oh dear. More packages implies more complexity.
Not necessarily.
Look, if the number of "essential" packages increases, then I agree
with you. But if the number of "optional" packages increases, it
should be a big so-what. If an essential package has RC bugs, the
release gets held up while the RC bugs get fixed. If an optional
package has RC bugs, it gets dropped from testing, or reverted to
an earlier version, before release. Adding 10 packages of text-based
python games wouldn't slow things down in the slightest; if they're
not ready, they'll get dropped from the release. During the sarge
freeze, periodic emails will come out from the release team saying
"these are the packages that are going to be dropped from the release
if their bugs aren't dealt with . . ."
Take a server set up web server, and we'll asume that be don't need to
trouble over lic, kernel.
Testing bare apache, no worries. The Apache Software Foundation releases
the software, Debian builds it in their recommended configuration, and
it "just works."
No releationships beterrn packages.
Add Perl support.
Now you have two packages to test, and worse, two releationships
Perl ==> Apache
Apache <==Perl
Build an ssl-capable version. Here are the new relationships
Apache ==> Apache-ssl
Apache-ssl <== Apache
Perl ==> Apache
Apache <==Perl
Perl ==> Apache-ssl
Apache-ssl <==Perl
Throw in a couple of OS databases, Jsp, Tomcat, Javabeans,
PHP{3,4,5},Python, webdav etc etc etc and there are quite a few
relationships that need to be tested.
And the databases, Perl, Python can hit stuff outside the webserver such
as mail....
This is why the number of packages is important.
That's why the number of packages can increase the number of bugs.
But the only one you named that's essential is perl. An RC bug
in perl would indeed hold the release back. An RC bug in apache wouldn't
(it's doubtful it'd get dropped, so I'd bet an earlier version would
get used; or, most likely, the bug would get fixed promptly by the
package maintainers).
The best predictor of the future is the past. Here is a summary of the
past taken from http://encyclopedia.fablis.com/index.php/Debian where
there is a table that summarises the critical points:
* 3.1* -- /sarge/, anticipated in 2004
* 3.0 -- /woody/, July 19th, 2002
* 2.2 -- /potato/, August 15th, 2000
* 2.1 -- /slink/, March 9th, 1999
* 2.0 -- /hamm/, July 24th, 1998
* 1.3 -- /bo/, June 2nd, 1997
* 1.2 -- /rex/, 1996
* 1.1 -- /buzz/, 1996
For why there was no 1.0 and what happened before:
http://www.debian.org/doc/manuals/project-history/ch-detailed.en.html
That's OK, I've seen this a zillion times over the years.
On the face of it,the delay "due to the new installer project" doesn't
seem so extraordinary.
If anyone has any insights as to what's changed that will reduce the
cycle time, please offer them.
There are really only two datapoints in the above that establish
the argument that releases have taken a long time: the release of
woody, and the pending release of sarge. Prior to that, I don't
think the release times were enormous. My understanding from
various DD posts in this mailing list over the last couple of
years has been that both releases were delayed with installer
issues (eventually culminating in the decision to go ahead with
boot-floppies for woody, lest the release be even further delayed).
If no major revisions to the release infrastructure are planned,
I dunno what would hold things up in a similar fashion. Certainly
the DDs seem a ton more excited about release times now; you don't
hear the "when it's time" argument anywhere near as often.