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@xxxxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
