Re: Frozen distribution?
[ moving to -devel ]
On Sat, 17 Feb 2001, Anthony Towns wrote:
> 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),
Katie should be fixed then.
> 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,
We could (and probably should) modify autobuilders so that they build
*only* for frozen during the freeze. We should only worry about unstable
after the release.
> 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.
This is more or less equivalent to frozen becoming unstable and
unstable becoming experimental. If we agree that testing allows us to
shorten the freeze period, this boils down to:
1. Create a frozen distribution and highly discourage uploads to frozen.
2. Don't create a frozen distribution, but then you have to convince
everybody to upload new packages for experimental, not unstable.
We have to change habits anyway, but I would say it may be easier to
convince people not to upload for frozen (after having established a
clear day D) than convince people to upload for experimental, not
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.
Moving things on request? You are joking, aren't you? :-)
Last time I asked a package to be moved from one *section* to another one
they took nearly one year to do the move...
Reply to: