Re: Some proposals
Allan Sandfeld Jensen made the point that been om my mind for some time.
"But what we really need is to decouple operating system and applications".
The debians update policy for stable is good for the 'OS' part - but a
bit troublesome for the apps sometimes. But i beleve that is salvable,
wihout allot of presure on developer (but it cost some resorces in
If deb:s that is part of the OS is marked in some way (libs many apps
depends on, related tools, probably parts of the development environmen
like gcc e t c). For desktop enverionments the libs, data and suporting
apps needed to run apps for them is 'OS' but the included desktop apps
themself is not? However, just imagen whe done a clasification off all
Then src-debs from unstable, that can autobuild on stable, is *not* 'OS'
and fulfill the regular 'testing' creterias can be (auto)build for
stable and moved to a stable-alfa-apps repository.
After beeing ther a couple of weeks without new bugreports they might
move on to a stable-beta-apps repository. Some 'OS' stuf (primarly new
stuff that dont break and mostly don't tuch the old stuff - maybe libs
for an new desktop-evironment majore version) may be manually allowed in
to the alfa repository (and later travel to beta). That to allowe for
new apps to be avalible for stable (to user that whants them only). This
probably would make it necesary to build stable-alfa-apps on
stable+stable-beta-apps+stable-alfa-apps, and stable-beta-apps on
As thes repositorys holds apps build with stable (or close to) as target
the alfa and beta repository is whell suited for pinning and the apps
ther probably will get great testing. Possably, but not nessasary,
stable-beta-apps can be considered for stable point-realeses (it's not
so imortant as they are relativly easy to get anyway).
Security updates need only go to stable - with prioritys in apt it shuld
be doable to downgrade alfa and beta apps in case of an security relese.
Security fixes shuld anyway come to unstable fast and be avalible to
alfa users - so no extra work for the security team shuld be needed!
For developers - they can choos to treat stable build errors as buggs,
or leave stable with the older version. The extra job to fix stable
build problems is usaly not big, and if they are - thats a good reason
to stop suporting new wersions on stable!
The testing repository can work just like now in the begining of the
relese cykel (both 'OS' and app debs get moved there). But when the next
realese is going in to freeze, all but manually aproved uppdate is
stopped to testing and a alfa and beta app 'que' repositorys is sett upp
for testing wher unstable debs goes, autobuilt for the 'testing'
environment (same scheme as stabel alfa and beta). Apps from
testing-beta-app (and possably somtimes alfa) is manually moved to
testing 'main' upp until the next stable relese.
Upon relese, the testing-alfa/beta-apps become stable-alfa/beta-apps
when testing becomes stable (broken apps might be removed from alfa and
beta first). Alfa/beta ques for the previus relese might be considered
(the old table alfa/beta ques) - at least upp to the next releses freez.
During that period ther is no testing alfa/beta apps que anyway, so
server load shuld be pretty constant over time. When it's time for next
freez, most people shuld feel confedent to upgrade to the then pretty
old and well tested stable relese anyway.
This would cost:
* more work for the autobuild host (and probably some work setting up).
* Probably some more load for mirrors (but probably moderate).
* Werry litle extra work on debian developers and teams.
And it would gain:
* More upp to date official app-debs avalible for stable (in a way the
user can controll, no destabilasaiton for produktion servers - just dont
use alfa and beta repositorys att all).
* And that probably mens better testing of apps and ther pakaging.
I'm not on this list, but have read the discussion in the archive. I
will look in the archive for replys, but pleas CC me if Yoo can.
Thanks for all Your work! Debian is great... and sory for the poor