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

Re: Future releases of Debian

 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.



Reply to: