update wiki.debian.net link
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 42:||Line 42:|
|Back to ["ReleaseProposals"]||Back to [[ReleaseProposals]]|
|Line 46:||Line 46:|
|See also this page, a proposal to the Debian Desktop project: ["WoodyOrSid"]||See also this page, a proposal to the Debian Desktop project: [[WoodyOrSid]]|
|Line 48:||Line 48:|
|And this release proposal mentions backports.org: ["AddAnotherRepositoryBetweenUnstableAndTesting"]||And this release proposal mentions backports.org: [[AddAnotherRepositoryBetweenUnstableAndTesting]]|
["ReleaseProposals") > FormaliseBackports
One thing that has made it possible for me to run stable on a fleet of machines is www.backports.org. (Thanks Nobse!) I suggest that some thought be given to formalising backports, possibly adding a section on the same footing as "main" and "non-free". Backports only covers one arch, so expanding this to all supported would be a major undertaking. It might be possible to do this by modifying the updates-to-stable process.
The reason for suggesting this is when coming to debian, people always trip over hardware that is common, supported by (some) other distros, but not supported by the kernels in "stable". Example of the month - SATA disk drives. But when etch comes to release, there will be something else. Perhaps it is possible to isolate the kernel and closely tied "kernel-kit" packages like mount, discover, hotplug etc, and provide updated versions of only those?
As there are quite a few kernel releases during the tenure of a debian stable release, I can see this could raise problems for the security team, in terms of the number of packages that might need patching. I'm not sure what to do about this.
One way to address this might be to make regular, 6-monthly releases of the installer; similar to what is proposed in ?DebianInstallerReleasesAreDebianReleases. This constrains the number of packages that require security updates, but possibly not by enough.
Also, there will presumably small changes in functionality, thus violating the "stability" policy somewhat. However the gain in functionality between "does not work on hardware XYZ" to "boots on hardware XYZ" is probably large enough to make it worthwhile. I would like to hear (again) the arguments about why absolute stability of functionality is important. If one must maintain all released versions of the kernel, then probably this proposal fails on the grounds of too much work for the security team.
However debian does have an update process, thanks to JoeyS and coworkers, and new versions of packages do enter there. Is it reasonable to consider modifying the update process by -
limit the scope of updates, by releasing on fixed dates (sorry , your package missed being updated, but don't worry, now you have 5 months to get it ready for the next update) and trying to get more helpers for that work
- allow the "kernel-kit" packages to be upgraded in this process
For this to work, the packages involved need significant time being tested. Above I suggested a "backports" section of stable, but this probably exists already, as the "stable-proposed-updates" distribution. What I don't know is how this is used at present; perhaps more use can be made of it.
Back to ReleaseProposals
See also this page, a proposal to the Debian Desktop project: WoodyOrSid
And this release proposal mentions backports.org: AddAnotherRepositoryBetweenUnstableAndTesting