Roger Leigh <rle...@codelibre.net> writes:
> I was considering this earlier, and had this idea:
>
> testing migration currently conflates two separate criteria when
> considering suitability for migration:
>
> ⢠the package is built on all architectures
> ⢠the package meets certain quality criteria such as bugginess, state
> of freeze, age since upload, etc.
>
> Consider that if these two criteria were split into migrations
> between separate distributions with the addition of a third
> distribution, which I'll call "pre-unstable" (equivalent to current
> unstable) in this example:
>
> upload â pre-unstable
> pre-unstable â unstable [migration when built on all arches]
> unstable â testing [migration when quality critera met]
>
> That is to say, "unstable" is entirely self-consistent in containing
> the same binaries across all architectures (where applicable).
> Binaries are only present here when built on all suitable
> architectures.
>
> If "pre-unstable" sources were autobuilt using the "unstable" binaries,
> it would ensure that the available binaries are identical across all
> architectures. "pre-unstable" is just a means of collecting binary
> uploads until it's uploaded for all arches, at which point it can
> migrate to unstable (which is a half-way house between current unstable
> and testing). The pre-unstable â unstable migration can also avoid the
> package dependency checks to migrate sets of packages used for testing
> migrations; the only point is to ensure unstable binaries are consistent
> across arches so the autobuilders always build against the same
> package set on all arches.
>
> I guess from a technical POV, this isn't too hard to do. The
> "pre-unstable" need not even be mirrored--it's just an internal
> implementation detail--buildds upload here rather than directly to
> unstable.
That indeed wouldn't be as bad as testing. It would slow down builds to
the speed of the slowest architecture though and any hickup on an arch
would deadlock unstable uploads. Uploading a new gnome or kde, where you
have >5 levels of dependent libraries, would take weeks waiting for one
or two archs.
Also toolchain issues, where a package temporarily just doesn't build on
some arch, would prevent a perfectly fine source upload from entering
unstable.
I think people rather draw the line at risking version skews than such
delayes and deadlocks.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739r81a6t....@frosties.localnet
