Finding an improved release process.
Note 1: This isn't meant to offend any deb developers or release people. You
all to a great job. Debian is full of very smart people.
Note 2: What this thread is about is finding a process for improving the
release process that Debian currently uses. While I do have some ideas of my
own, I'm not bold enough to suggest they should be the ones followed.
**************************************************
Here's a little history of Debian since 2.0 [hamm].
1998-Jul - 2.0 - hamm
1999-Mar - 2.1 - slink
2000-Aug - 2.2 - potato
2002-Jul - 3.0 - woody
2004-Dec or later - 3.1 - Sarge
If we have a look at time between releases we see:
Hamm
8 months pass
Slink
17 months pass
Potato
23 months pass
Woody
30 months pass
Sarge [if it releases 2004-Dec which it may not]
36 months pass
Sarge+1: 3 years later if current trend continues [2007-Dec].
Without putting too much faith in the above figures, you can see that
currently we can expect to wait <time of last release development time> + 6
months for a Debian release.
We all know that Debian is a special distro [so many archs, so many packages]
and something like a bi-annual release schedule wouldn't be feasible.
But we can't even say "debian has a lot of stuff and we make sure everything
works, so we release every [12/18/24] months".
The time between the releases are increasing!
We like to say we release "when it's ready", but I think we need a better
process.
*************************************************************
Before suggesting a few points that need to be taken into consideration; I'd
like to ask:
How can we find an improved release process?
Plenty of people have made various suggestion on this list. We get threads
with hundreds of messages, with debate being more rational in some places
than others. This may not be the most optimal approach.
Here's one idea for doing this. Obviously this would just be a starting point
and may not be the best approach.
I'd like to suggest perhaps we set up a web site of proposals for improving
the release process. The proposals would be more thought out and written much
more carefully than just a braindump to debian-devel. Perhaps a good idea
would be to have such things co-authored with like-minded individuals.
Perhaps it could have sections with pros & cons of various strategies [e.g.
time-based schedule, drop testing, remove archs, some other crazy ideas, give
up :) ] If someone comes up with a proposal that you think stinks, you could
right a rebuttal that is also carefully written and thought out. Currently
the approach can be a reply like: "you smoke crack! You are an idiot and
don't know what you are talking about. piss off and die!" Flaming doesn't
help a great deal.
Perhaps a starting point would be to collate the best
proposals/suggestions/rebuttals from the lists in the past, and have a
centralised place for such information.
*******************************************************
Things to think about.
=============
* Desktop vs server. I currently use debian for my desktop/development
workstation. I'm sure most of you do too. Do we need to identify and specify
that we are for desktops just as much as servers?
*
<main potential point of controversy?>
The importance of releases!!!
People often suggest running testing or unstable. "It's just as stable as any
distro". I have never agreed with this. The reason for this is that neither
are engineered or intended for being an end product.
If I run unstable I can expect to have a fairly stable machine. But sometimes
I may update and things will be broken.
The same goes for testing. Yes it all works smooth *MOST* of the time, but
there will always be times when this is not the case. Unless you can tell the
user that they install/update/upgrade anytime 24/7 with the same unbroken
result you can't recommend these systems.
</main potential point of controversy?>
Thankyou,
Lex Hider.
Reply to: