Gentoo Archives: gentoo-dev

From: Richard Freeman <rich0@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] QA Documentation
Date: Mon, 28 Dec 2009 14:46:45
Message-Id: 4B38C4C4.90306@gentoo.org
In Reply to: Re: [gentoo-dev] QA Documentation by "Tomáš Chvátal"
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.