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

[Josh Boyer]

2011/9/20 Miloslav Trmač <mitr at volny.cz>:
> On Tue, Sep 20, 2011 at 4:57 PM, Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
>> On Tue, Sep 20, 2011 at 04:52:28PM +0200, Ralf Corsepius wrote:
>>> On 09/20/2011 04:37 PM, Matthew Garrett wrote:
>>> >What the maintainers could have done is not upload a package that breaks
>>> >binary compatibility into a distribution that's attempting to stabalise
>>> >for release.
>>>
>>> That's a way too simplistic view - It's simply that other processes
>>> (upstream release cycles, upstream release processes, package
>>> maintainer's time slots, etc.) are not in sync with Fedora's cycles
>>> and that Fedora's wanna-be QA's delay slots are severely adding to
>>> the already existing problems.
>>
>> You're not obliged to upload the latest upstream. It's very practical to
>> simply not do so.
>
> So when _is_ a good time to do binary-incompatible changes to libraries?
>
> * It's not after beta freeze, because they are unwanted at that time
>
> * It's not 14 days before beta freeze, because they won't get out of
> updates-testing in time
>
> * It's not 14 days + 3 (4?) weeks before beta freeze - even if the
> library gets out of updates-testing in time, its users may not be
> rebuilt because the maintainer is on vacation.
>
> * What if there are two layers of users that need to be rebuilt?
>
> The delays just pile one upon another...

You can update rawhide at any time and accomplish that work without
delays.  Then it shows up in the next Fedora version.

josh