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