On 12/28/2009 06:23 AM, Tomáš Chvátal wrote:
we should ENFORCE it, not just fill bugs about it, because mostly people tend to ignore that things.
Agreed, although some presumption of innocence should be assumed. If a dev is ignoring repoman output that is a fairly big violation, but if a dev missed that compiling under some strange set of circumstances or combination of use flags causes a problem, well, that's a bug that needs to be fixed. There were some --as-needed issues detected by the tinderbox that only show up when you use a modified gcc profile, for example. That doesn't mean they're not worth fixing, but we shouldn't punish people for that stuff.
I don't think the QA team has an issue with mistakes (not that I can really speak for them) - their main frustration is probably when bugs get filed and then get ignored. Expecting people to resolve bugs in a week for minor issues is probably asking a bit much, but if a dev has 14 packages with 25 open bugs each that are six months old that is probably a cause for concern that should be escalated to devrel.
On the other hand, some allowance for brain-dead upstream tactics should be made. I'd consider embedded libraries a QA issue, but if we made that a stern policy we'd never see chromium in the tree for quite a long time. I'm sure the guys maintaining that would love to try to patch out as much of the embedded stuff as they can, but they've got a LOT of work to do due to the way it was written. I'm not sure that simply banning chromium from the tree is the right approach either as long as upstream deals with the inevitable security issues when they come up.
