pushing updates for FTBFS

[Hans de Goede]

Hi,

On 09/22/2010 07:37 PM, Toshio Kuratomi wrote:
> On Tue, Sep 21, 2010 at 03:25:25PM -0600, Kevin Fenzi wrote:
>> On Tue, 21 Sep 2010 10:06:09 -0700
>> Eric Smith<eric at brouhaha.com>  wrote:
>>
>>> A bug was filed against meshlab because of an FTBFS for Fedora 14.  I
>>> added a patch to resolve it and submitted an update.  After seven
>>> days with no feedback, I was able to push it to stable.
>>
>> Were there reports of the existing build causing problems?
>>
>> Personally, I would check such changes in, but only push out an update
>> in f14 if there were other changes that made it worthwhile, or the
>> existing build caused issues.
>>
>> Rawhide of course you should build for for these issues.
>>
>>> For an FTBFS for a new Fedora release, does it really make sense to
>>> have the seven day delay?  I don't see what the downside would be of
>>> allowing it to be pushed to stable immediately.  Even if there's
>>> something wrong with the update, it isn't going to replace a working
>>> package.
>>
>> I don't see the point of pushing it as an update at all, unless it's
>> fixing some bad behavior in the existing build or there are other
>> reasons (upstream update, etc).
>>
> For (unreleased) F14, I think that the arugment that future work on the
> package is better off starting with something that works than to start off
> with something that's broken by new gcc, boost, etc is very valid.
>
> If I get a time-sensitive security bug about foo in Fedora 14, I want to
> have as few extraneous issues as possible so I can hunt down and fix the bug
> quickly.
>

Right, and on top of that, fixing ftbfs woth an update (for unreleased
versions only) also makes live a lot easier for secondary archs if it does
not build on i386 chances are almost 100% it won't build no ppc / arm / alpha
/ sparc / s390 / whatever either.

Regards,

Hans