pushing updates for FTBFS
Hans de Goede
hdegoede at redhat.com
Fri Sep 24 12:12:04 UTC 2010
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
>> 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
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.
More information about the devel