acceptability of updates-testing breakage vs. rawhide breakage

[Michael Scherer]

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.

-- 
Michael Scherer