Am Sonntag, den 14.05.2006, 20:09 +0200 schrieb Michael Schwendt: > 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. :) You mean as a example? Okay. > Let's assume extras-testing is covered by a repoclosure report. It of course should. > 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? Well, that a case where manual interaction might be required for now. But it's still better then now where the breakage would immediately would have hit the proper repo. > 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) Still a lot better than the current situation. > Conclusively, what we need to shield our users from broken updates You seem to always center around broken updates with deps -- I mainly think about new version from upstream or newly introduced bugs in out packages that are buggy in general or on Fedora. > 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). Sure. > > > 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. No. Fifo into testing for *all packages* except security fixes. No build target "extras". I never proposed that. And that's the point where we missunderstood each other afaics. > I smell chaos and extra burden. Yeah, that would be correct if we would have a build target "extras" -- but that's not what I propose. It might make a bit chaos when security updates get to the extras repo directly. But that's IMHO a acceptable and not that big problem. > Think fedora.us unstable/testing/stable. [...] Yeah, that really wasn't that ideal. CU thl -- Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
