On Sat, Jan 11, 2014 at 10:59 AM, Michael Scherer <misc@xxxxxxxx> wrote: > Le vendredi 10 janvier 2014 à 09:56 -0500, Chuck Anderson a écrit : >> On Thu, Jan 09, 2014 at 10:42:33AM -0800, Adam Williamson wrote: >> > On Thu, 2014-01-09 at 10:13 -0500, Chuck Anderson wrote: >> > > This appears to have also broken Fedora 19 updates-testing, which is >> > > even less acceptable than breaking rawhide. >> > >> > Eh, I'd suggest not. updates-testing is actually explicitly meant as a >> > place to catch this kind of problem, whereas we're trying to keep >> > Rawhide rolling and especially try not to break nightly image >> > generation. At least we can vote broken things in updates-testing down. >> >> Wow, really? updates-testing is allowed to be more broken than >> rawhide? So why don't we just do all development in updates-testing, >> and don't push these changes to rawhide until they pass the >> updates-testing karma? >> >> This is not how I understand these things should work. I think this >> attitude will push even fewer people to run with updates-testing >> enabled. > > > Out of anything that can happen during a update, having small broken > deps is the most visible and the less problematic one. People focus > because that's visible, but it doesn't break anything ( ie, your system > still boot, it doesn't start to segfault or eat your data ), and can be > reverted quite quickly by maintainer, and avoided by the tester using a > option to yum. > > People are working on taskotron ( successor of autoqa ) and this will > likely prevent this kind of issue in the future, I hope. If you feel > that's important to make sure this doesn't happen, they will always > accept any kind of help. But in the mean time, as this is IMHO the most > beging type of breakage, I think we can tolerate them from time to time > until we can properly automate the checking. We do have the automated checking we just don't use it. (autoqa does dep checks but we do not do any action on them; the updates causing broken deps should simply be unpushed). -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
