Re: pushing updates for FTBFS
On Wed, 22 Sep 2010 16:39:00 -0400 Toshio Kuratomi a.bad...@gmail.com wrote: The problem is that we'd want to know what the ramifications of the update are to the release. What if the fix for the FTBFS causes an ABI break... but it's also the only way to fix the FTBFS within our manpower needs? Better to do that before F14 has shipped than be forced to do that after it has shipped. I can come up with other scenarios that are similar but they're all just about identifying what cascading problems could occur up front rather than defering it to when we have a time-critical update to get out the door. True. So, I guess it gets down to why the thing was FTBFS and what needed to be done to fix it. In the past, all the ones I have had have been minor linking or build options that didn't seem to affect the end package much, but of course there could be other cases. So, yeah, you may be right that we should push these to branched releases as well just to be sure... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
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 Smithe...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
On Tue, Sep 21, 2010 at 03:25:25PM -0600, Kevin Fenzi wrote: On Tue, 21 Sep 2010 10:06:09 -0700 Eric Smith e...@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. In released Fedora's that argument starts to lose weight because the window in which a bug that *must* be fixed could be discovered goes down (ie: F12 only has a few more months of life so there's a much smaller time period in which a must-fix bug could be discovered. (OTOH, fxing FTBFS in a just released Fedora is probably still a good reason to update.) -Toshio pgp71rCTfhXeR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
On Wed, 22 Sep 2010 13:37:44 -0400 Toshio Kuratomi a.bad...@gmail.com wrote: 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. Sure. I would suggest fixing the issue and even commiting the fixed spec, but I don't know that it's worth pushing an update out for. 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. Yep. Also, if someone wants to build your package and fix something or test something it's nice to have the fixed version sitting there ready in git. In released Fedora's that argument starts to lose weight because the window in which a bug that *must* be fixed could be discovered goes down (ie: F12 only has a few more months of life so there's a much smaller time period in which a must-fix bug could be discovered. (OTOH, fxing FTBFS in a just released Fedora is probably still a good reason to update.) I suppose, but it seems like it's just wasting our users time unless it fixes something that the user would see. If it's just fixing a build issue, but the program is the exact same version and behavior, didn't we just waste resources pushing it out to the user? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
On Wed, Sep 22, 2010 at 12:38:50PM -0600, Kevin Fenzi wrote: On Wed, 22 Sep 2010 13:37:44 -0400 Toshio Kuratomi a.bad...@gmail.com wrote: 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. Sure. I would suggest fixing the issue and even commiting the fixed spec, but I don't know that it's worth pushing an update out for. The problem is that we'd want to know what the ramifications of the update are to the release. What if the fix for the FTBFS causes an ABI break... but it's also the only way to fix the FTBFS within our manpower needs? Better to do that before F14 has shipped than be forced to do that after it has shipped. I can come up with other scenarios that are similar but they're all just about identifying what cascading problems could occur up front rather than defering it to when we have a time-critical update to get out the door. -Toshio pgpU8gIPCUBaS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
pushing updates for FTBFS
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. 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. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
On Tue, 21 Sep 2010 10:06:09 -0700, Eric Smith wrote: 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. Just because the package is no longer buildable does not mean the existing build no longer works, though. Case in point: the breakage of C+ + programs every time the GCC compiler suite is updated, due to stricter standard compliance in the new compiler version. It's arguable that, in that case, since the maintainer has to do some patching themselves, that having a test period is actually more essential than is normally the case, when it's the upstream developers that touch the package. -- Michel Alexandre Salim, MSc., University of Erlangen-Nuremberg Open Source Research Group, Applied Software Engineering Web: http://osr.cs.fau.de, Email: michel.sa...@cs.fau.de GPG key ID: D09272F7 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
On Tue, 2010-09-21 at 10:06 -0700, Eric Smith 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. 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. This has come up multiple times, and the reply is always the same: yes, an update *can* be worse than a non-buildable (or even not working) package. It could somehow break *other* parts of the system. It could introduce a security vulnerability. You don't have to wait seven days. You just have to find someone to test the update. If you don't know anyone who uses your package, now might be a good time to find someone. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
On Tue, 21 Sep 2010 10:06:09 -0700 Eric Smith e...@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). All just IMHO. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
Kevin Fenzi wrote: Were there reports of the existing build causing problems? I don't think there was any prior F14 build of meshlab. I got email for the FTBFS bug. 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). If I hadn't pushed an update to F14, would the F13 build appeared in the F14 repository? Thanks, Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
On Tue, 21 Sep 2010 18:49:13 -0700 Eric Smith e...@brouhaha.com wrote: Kevin Fenzi wrote: Were there reports of the existing build causing problems? I don't think there was any prior F14 build of meshlab. I got email for the FTBFS bug. Yeah, there was a 1.2.2-4.fc14 build. http://koji.fedoraproject.org/koji/buildinfo?buildID=173392 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). If I hadn't pushed an update to F14, would the F13 build appeared in the F14 repository? If there had not been a f14 build at all? yes. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
