Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)
On Mon, Aug 25, 2003 at 07:42:13PM +0100, Mark Howard wrote: > Hello,
> I'm glad to hear so many people agreeing with the RM's plans and even
> more glad to see so many things being done to make this seem plausible!
>
> I'm one of those developers who has cvs and other unrealeasable packages
> in sid. I agree with the comments about moving these to experimental,
> keeping sid for just releases considered stable, but think changes need
> to be made to experimental so that people do this by default and so sid
> will be even more stable:
>
> Split experimental into sections:
> - I don't like having an experimental base system, but would like to try
> out the latest gnome desktop.
> experimental-core - new major upstream releases of core packages
> experimental-gnome - gnome 2.3, galeon2.3, epiphany...
> experimental-kde
> experimental-gnome-woody - backport of gnome2 to woody
> experimental-all - includes all of the above (well, almost)
> ...
> sid - candidates for future Debian stable. All considered stable
> releases upstream.
> Ideally, creating new sections should be as simple as sending a message
> to the ftp-masters.
Nice thing, i am in favour of it also. But as i understood it, the
infrastructure is not upto it yet.
I even think that each sub-part of debian should have a separate
autobuilt experimental pool, and would be responsible for release
management to unstable issues for it, with the possibility for the RM to
veto it, or possibly to easily revert a experimental->unstable
migration.
Furthermore i feel than major library changes should build as much other
stuff as it can in their experimental pool shortly before migrating to
unstable. This would result in double work, but is the only way that
things like libc6 would get enough testing and ensure that it does not
break anything when it moves to unstable (and thus properly moves to
experimental afterward).
If we don't rebuild every dependant package in the experimental pool,
we need then to have a way to eventually retrigger the build of every
dependant package once it reaches unstable.
That said, ideally all packages would be rebuilt in the experimental
pool with in an automatic triggered way and then only can the library
component migrate to unstable, in the same way as stuff migrate from
unstable to testing in this way.
Special care would need to be taken for uploads of new stuff when one of
the library pools is waiting to move to unstable.
Friendly,
Sven Luther
Reply to: