On Sun, 14 May 2006 17:21:00 +0200, Thorsten Leemhuis wrote: > But we simply could use the current scheme > until then: packages foo1 and foo2 are build and a particular point in > time and pushed to the testing repo together and another point of time. > bar1 and bar2 get build some days later and also pushed to testing > together. Five days after foo1 and foo2 were pushed both pacakgers are > moved from testing to the proper repo. bar1 and bar2 would follow > together five days after their push. foo1 and foo2 break dependencies in extras-testing. :) Let's assume extras-testing is covered by a repoclosure report. Still, only after 2-3 days a real user gets nervous and reports the breakage. A day later another packager, who receives the reports, rebuilds his packages bar1 and bar2 to fix the broken deps and pushes the builds into extras-testing. So, how do you forward the entire set into extras finally? If it's done automatically, foo1 and foo2 are pushed several days before bar1 and bar2. (yes, it needs somebody to push all four packages at once, something that has failed several times before for Core, btw) (Or Possibly you want to resolve all deps automatically, but in that case it might happen that foo1 is 7 days old, while baz2 has just been built, and then you might wait to give the set some longer testing) Conclusively, what we need to shield our users from broken updates is more careful packagers, more communication and coordination of upgrades which affect dependencies, and convenient access to a scratch target in the buildsys, so not every packager must set up mock and local mirrors of multiple distribution releases. And of course guidelines and hints on how to avoid common upgrade mistakes (like SONAME changes). > > So, Extras packagers must watch another moving target? > > What do they have to watch precisely? I only seem problems when some > packages are pushed directly to the repo. That should only happen for > security issues -- we IMHo should be able to handle that. As soon as any package, which has dependencies in Extras (whether at build-time or run-time, doesn't matter), is pushed into extras-testing, the affected Extras packagers must do their own preparations and testing against the new stuff in _extras-testing_. And unfortunately, they have the choice between two build targets now, "extras" and "extras-testing", which gets particularly funny when security fixes join the show. I smell chaos and extra burden. Think fedora.us unstable/testing/stable. At first we liked it, and possibly considered the classification of new packages as helpful. It was less easy for version upgrades, cvs snapshots and added packages to reduce the total number of installable/usable packages in the main repository through breakage. And we had to fill the repository with more and more packages without being confronted with breakage too often. But what has happened later? At least "testing" became quite crowded and made it more difficult to concentrate on the packages we wanted to see in use by our users. To decide whether test packages were good enough, developers and users needed to run "stable" and "testing", getting the entire mix of packages. And that is ugly. At the current pace updates are pushed out at Fedora Extras, extras-testing would be filled with packages constantly. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
