Hello, I want to preface this by saying that I read about it in the Debian Weekly News and have not been following the thread nor have I read all the followup posts. Furthermore, I'm not even subscribed to the list - but I've given some thought to this anyway.
I think that while this is a step in the right direction, that it would not actually have the intended effect.It seems to me that any packages that get promoted to 'working' are still going to have to go through a QA proceedure - it can't just be uneqivocably promoted to a 'stable' release. I think that using the same basic scheme but adding another level might allow this to work better. Instead of the seemingly three-tiered design, I would like to suggest a four-tier: stable (release) frozen semistable unstable I should also say that I'm not a Debian Developer, so feel free to take with a grain of salt -- but it seems to me that a good development scheme would be to upload all new packages into unstable where things like the broken fsck can get hashed out without affecting so many people. Packages live in this staging area for ``x'' time (72 hours?) and if they are not updated and no bugs have been filed against them, they are automatically upgraded into the "semistable" area. This is where I would see "cutting edge" users apt-get'ting from, with most (all?) developers updating from unstable. After some time (1 month?) the packages in semistable can be opted up to 'frozen'. This scheme could use the same for the original proposal for process pools, with the maintainer having the ability to disallow the package being updating (for instance, a security hole was found and fixed in a later package, but the fix breaks a dependency so it has to wait). The ideal goal for frozen is to act as any other frozen - to produce a stable release. I don't expect a new release each month, however, so maybe frozen is a bad name. frosted? chilled? But the ultimate goal would be to freeze "frozen" at some point (6 months, 9, as a goal?) to produce a solid release, without having to remain frozen for two months or more. I don't know the overhead or administration that is involved in such a measure, but, to me, this seems like a reasonable scheme with no real drawbacks. Questions may arise to the purpose of 'frozen' and/or "semistable" (the others seem to reflect the initial proposal), and I'm not wholly sure I could successfully argue them. The difference, though, is that the promotion from unstable to semistable is automatic - the developer does not have to do anything different. The idea here is to add a layer of security for goofups (package item misspellings, bad / corrupt / inoperable packages, etc). Similarly, the promotion from semistable to (how about) "freezable" is also automatic, provided all dependencies can be met. The developer has the option to disallow the promotion, though. The "freezable" layer can act as the main update layer for those who want updated packages with more trust. I was thinking that when "freezable" was sufficiently complete (eg, no perl5.0005 or XFree86 type issues) it could become officially "frozen" in preparation of a new stable release. During it's "frozen" time, of course, the automatic updates would stop. Perhaps a fifth layer, "frozen" is needed as well to handle this properly. But those are my thoughts after grinding on this for a few hours today. I like the idea of an additional layer between 'unstable' and 'stable' (or frozen, if you want to think there's already a three tier design). But I do fear that it's not wholly there yet. The addition of a 'freezable' layer above 'semistable' would make freezing easier as well as give a better idea of where things stand, and would be needed if the promotion from 'unstable' to 'semstable' is automatic. I think it's not a good idea to force the developer to determine if their package is ready, when the system can do a pretty good job of it itself. The developer should be able to prevent the promotion though. $0.02 Christopher
