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

Panu Matilainen pmatilai at laiskiainen.org
Tue Sep 20 18:11:24 UTC 2011


On 09/20/2011 08:19 PM, Nicolas Mailhot wrote:
> Le mardi 20 septembre 2011 à 17:10 +0200, Miloslav Trmač a écrit :
>
>> So when _is_ a good time to do binary-incompatible changes to libraries?
>
> The answer is obvious - in rawhide, before branching point. Anything
> after branching will interact with various groups schedules and crash
> into the barriers put in place to try to bring some order to the
> release.
>
> Now of course that supposes rawhide is kept in dogfoodable state and
> people don't let problems fester there because 'it eats babies, so who
> cares'

Also related to rawhide dogfoodability is this recent trend where after 
a branch point, "all" work appears switch to the branched distro, 
resulting in branches having newer packages than rawhide and such. This 
was very visible at least after F15 branching, this time around I 
haven't paid enough attention to comment whether its the same now.

The effect of this is that the "active rawhide window" *seems* awfully 
short these days, because rawhide is relatively quiet for large number 
of packages during branced state. That's not how the branching procedure 
intends this to work, but that's how it seems to go in practise to a 
large extent.

My personal pet-peeve with the current branching policy is that the 
mass-branching happens way way too early for packages where there are no 
significant new development to be introduced in rawhide during branched 
state. So for every single tiny fix that needs to go in, it needs to be 
built into rawhide and also branched. Minor annoyance maybe but annoying 
things tend to get negletted - perhaps this is one of the reasons for 
rawhide lagging behind branched.

	- Panu -


More information about the devel mailing list