On Sat, Feb 17, 2001 at 01:46:46PM +1100, Brian May wrote:
> >>>>> "Julian" == Julian Gilbey <J.D.Gilbey@qmw.ac.uk> writes:
> Julian> On Fri, Feb 16, 2001 at 02:04:24PM +1100, Brian May wrote:
> >> What is the benefit of this new frozen stage, instead of just
> >> freezing the testing stage?
> Julian> That people who want to be almost bleeding edge will be
> Julian> held back for three months of freeze.
> Why?
> You can just use unstable like you currently do.
> There is no reason why unstable should change just for the freeze.
Actually there are two reasons why unstable should change just for the
freeze. They're complementary.
If you don't fork frozen (ie, maintain unstable and frozen independently),
then if you upload major changes to unstable, you've stopped yourself
from being able to upload minor bugfix updates to frozen (since they're
not forked, you'd have to upload it to unstable, which has already been
majorly changed).
OTOH, if you do fork frozen, then you cause problems on "other"
architectures. Uploads that are sent to both places ("frozen unstable"
uploads), tend to get autobuilt twice (once for frozen, once for unstable,
which no longer works with katie), or misautobuilt (built with unstable
libs on the unstable autobuilder and uploaded to frozen as well), or not
built at all on one or the other. Uploads that are (mistakenly?) sent
to just one or the other (we've had both) either break in the current
release we're trying to get out, or end up broken in the next release when
we find the .deb is outdated or not at all present in unstable anymore.
The easiest solution that I can think of (ie, that doesn't cause difficult
to detect breakage, and that doesn't involve further significant changes
or too much awkwardness) is, during the freeze, to just upload major
changes to experimental, and bugfix updates to unstable.
Thanks to the changes James has already made, uploading to experimental
should be pretty easy (no waits for NEW processing unless the package
really is new), and experimental tends not to be autobuilt so shouldn't
cause problems there.
Once the freeze is over and the release is made, it'd be fairly easy to
move packages from experimental to unstable on request, if nothing else.
I'd like to avoid manually processing uploads where possible though (which
is what traditional freezes involve), and ideally use a minimum number of
suites (stable, testing, unstable, experimental). But if people have other
suggestions, or, even better, clever tweaks to the above, that'd be cool.
This may or may not be appropriate to this list at this point, feel free
to move it to... -devel, I guess?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpDTRQO5_69Z.pgp
Description: PGP signature