Re: Future releases of Debian

[Christian Fasshauer <mseacf@gmx.net>]

 Adrian Bunk wrote:

> On Sat, Jul 19, 2003 at 08:49:29PM +0200, Christian Fasshauer wrote:
>  
>
> > ...
>
> It's not technically impossible, although it's a non-trivial task if you
> want to do it right. 
Perhaps, it could be as far as possible automated. And the 
implementation effort shouldn't be to hard because the dependency and 
package stage check which decides to put a package from unstable to 
testing works very well and acts actually similar.

> It would be some kind of official backports. In my
> opinion, backports of more recent packages to an outdated Debian stable
> are only a workaround, not a good solution. 
For woody is there really not a  chance, but after finishing sarge it 
could exist a level after testing which contains software, possible to 
be inserted into sarge. And this container is filled up the whole time 
and becomes emptied sometimes and this is the update. Even new packages 
could be introduced in that fashion.... However, each developer should 
try then to use dependencies that are as low as possible different (but 
working) from the current release. Or a second testing group needs to be 
created which checks the lowest possible dependencies. The reducing 
product would have a quality between stable and testing.

> The real solution is to get 
> a stable release of Debian at least once a year.
>  
I would be really thankful for that, but this could become a quite more 
difficulty task. I think, no Debian Developer wants to slow down the 
process of finishing a new Debian release and the amount of software 
grows up. Perhaps means more software more time for a result. ;-)

> A real problem I see with this approach are security updates: 
> Consider your suggested recent packages three times a year and support 
> for two years. Then a security fix in a popular package has to be done 
> for half a dozen different pacakges.
>  
This is true. One option would be to cut off the optionality to apply 
security and/or recent updates and put both together which will 
substitude the well known security updates to those who are more recent 
and brings new bugs. I think, most of you wouldn't like that.
A second way could be to split off the user goup to those who want a 
secure system for their servers where recent software is not necessary. 
The other group works every day on the system and want software which is 
not some years old. This group gets the possibility to update the system 
a few times a year, but giving up for that to perform secutiry updates. 
The recent software update contains more recent but stable packages, 
build as described above with security updates as far as the version of 
the program allows it.

>  
>
>
> cu
> Adrian
>
>  
christian