Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
nils at redhat.com
Wed Sep 21 14:43:38 UTC 2011
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
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
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils at redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
More information about the devel