On 09/21/2011 01:25 PM, Nils Philippsen wrote: > On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote: >> On 09/20/2011 05:52 PM, Nils Philippsen wrote: >>> On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote: >> >>>> When you have a closer look, you'll notice that such "mass rebuilts" >>>> were being delayed by QA's "delay queue" and now are stuck. >>> >>> I didn't want to (re)start that particular discussion ;-). >> > >>> We need some guidelines who should drive rebuilds in such a situation, >>> regardless of whether it happens in Rawhide or Branched or wherever. >> a) These situation can only happen in release branches. > > Uhm, no. A library SONAME bump can happen in Rawhide as well as in > branches and if dependent packages don't get built with the new version, > things are broken. Right. They break in rawhide, where issues are inevitable and can be addressed within short terms because maintainers are not being forced to play "10 days per package update" "you wait for me/I wait for you" delay ping-pong. Or am I misunderstanding? Are you referring to points in time when "stable fedoras" are being sync'ed and inherit "broken deps" during this fork? If this happens, something would be very defective with Fedora's rel-eng's procedures. The situation currently to be found in f16 is "longer dep chains" being in inconsistent build-state (showing as broken deps), because fixed packages in *-testing did not make it into "stable" in time because of these QA delays and because Fedora policies _forbit_ fixing these at this point in time. > Waiting for dependent components to be built at their > maintainers leisure or whenever a mass rebuild comes around isn't a > solution, not if we want to have a "more stable Rawhide". To we want this? I don't. To me, rawhide is the "big package dumping ground" for the bleading edge". Certainly, it should be as little broken as possible, but "its brokenness" is part of its working principle and inevitable to me. That said, I find a stable "rawhide" to be nonrealisting and inapplicable. Ralf -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
