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