Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
jwboyer at gmail.com
Tue Sep 20 15:30:35 UTC 2011
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.
More information about the devel