Re: Future releases of Debian
Adrian Bunk wrote:
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.
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.
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.
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.
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.