On Wed, 2011-09-21 at 15:51 +0200, Ralf Corsepius wrote: > 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. And that's always fine and dandy if these issues are resolved in a reasonable amount of time. Right now Rawhide has packages with dependencies broken since pre-F15. This isn't acceptable. > 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. I'm not talking about branched Fedora vs. Rawhide at all. I thought I made myself clear on that. > > 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. You're twisting my words a bit. I wasn't opting for a stable, but a more stable release. If somebody wants to test something in Rawhide they shouldn't have to debug other parts of the distribution. This means that changes should be done with enough circumspection that breakage is reduced to a minimum. People who actually run Rawhide (and I know their number is low) would thank us for that. Right now this is not the case: a substantial number of components is broken due to unsatisfied dependencies alone, meaning that everybody who wants to test Rawhide in conjunction with anything on that list is simply out of luck right now. I admit that the impact of being broken is not the same for every component in the distribution: some stuff more on the fringe is sufficiently isolated that it will only affect few testers if it doesn't work (ideally the ones fixing the breakage), so it won't hurt many if these are broken for a longer time, but other components are central enough that they can't afford that luxury. It would certainly help here if buildroots could be created for Rawhide so that breakage can be resolved in isolation there. In this case they'd need to be created before the first package is built however, so it doesn't break unrelated builds. This is because we don't file Bodhi updates for Rawhide packages (nobody in their right mind would want that). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
