On Wednesday 25 October 2006 09:36, Michael Schwendt wrote: > Packages published in "testing" are available to every subsequent build > job that targets "testing", too. They can be build dependencies. When > moving packages from "testing" to "stable", it's means "all or nothing" > for a dependency-chain. Same applies to withdrawing packages from > "testing". Same applies to holding up packages. This is something I have to deal with internally many many times a week. Our updates-testing collection does not self update, so any time somebody needs to build a set of packages for testing (kde, gnome, mono stuff, any low level package, etc...) I have to do some tagging of some packages to make them available in the buildroot, which defeats the purpose of keeping them separate to begin with. To combat this, what we need is the ability to submit a build and request that certain packages be brought into that specific buildroot, provide a list of package builds that could be found in the packageDB no matter what collection they may be a part of. This is kind of scary too and I don't think its a great solution, but I don't have many others off the top of my head to deal with the split between testing and live. Unfortunately I also feel that the -testing repo does serve a good purpose. It would have caught the KDE fiasco in Core5 (or was it 4?), we make great use of it for testing kernel updates, or adding new features, or doing major version bumps. I see the only other alternative as being personal repo pages (very low probability of widespread testing), or a much more restrictive rule set on what is allowed to be issued as an 'update' to a released product. For development/, please. Development/ exists for people to test the packages that are candidates for the next release. Having test repo for a test repo seems silly to me. Your chance to validate the package for the next release _is_ rawhide. -- Jesse Keating Release Engineer: Fedora
Attachment:
pgpR75LvyEtUm.pgp
Description: PGP signature
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
