Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

Ralf Corsepius rc040203 at
Wed Sep 21 13:51:06 UTC 2011

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 

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.


More information about the devel mailing list