[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: