On Mon, 2011-09-12 at 13:43 +0200, Kevin Kofler wrote: > If something fails to COMPILE, this actually hinders development. In fact, > I'm one of the first ones to yell if package builds in Rawhide are broken > (due to some dependency breakage or whatever). Something failing to RUN is a > wholely different matter, which is not covered by the average "don't break > trunk" rule (which is usually about compilability). I disagree. The "don't break trunk" rule is about other people's changes not getting in the way of the work you're doing. There's no qualitative difference, really, between software that doesn't compile and software that compiles but doesn't run. So, in this instance, sure - if you have a library which cannot be linked to and thus prevents you building your package, that's an obvious road-block. But if you can build your package but the resulting package doesn't work, is that any less a road-block? I guess if you adhere to the "eats babies" principle you can still toss it out there and consider it done; personally, I would consider it a road-block. I would love to see many more automated sanity checks and QA tools available in the build process, like AutoQA, but these should be in addition to what a maintainer is already doing - I'd hope/expect that 95% of the time these aren't catching any problems. They're just another check. So, as an obvious example, I don't upload packages when I know I'm not going to be around for a few days afterwards. No automatic tool is ever going to enforce that, it's a purely personal cultural thing. I do this because I know when stuff breaks it's vastly more noticeable at weekends or other times when maintainers aren't around to clean up. I consider it to be good practice, and polite behaviour, even though the stuff I'm pushing probably doesn't affect many people at all. But I do it because I don't want my stuff eating babies. Cheers Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
