A `second' to the ``package pool''
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
Reply to: