1 |
On Wed, Sep 14, 2005 at 12:06:13AM -0400, Curtis Napier wrote: |
2 |
> I'm not an ebuild dev so I may not know enough about this situation to |
3 |
> competantly comment on it but it seems to me that QA should have some |
4 |
> sort of limited ability to "temporarily" take away write access to the |
5 |
> tree until devrel has a chance to look over the evidence and come to a |
6 |
> decision. This would fix the problem of "devrel takes to long" plus it |
7 |
> would really help to ensure higher quality work is submitted (because |
8 |
> ebuild devs WILL stop purposely commiting bad work if they know a QA |
9 |
> team member can take away their write access at a moments notice for |
10 |
> repeated violations). |
11 |
|
12 |
The other thing that'd fix the 'devrel takes so long' problem would be |
13 |
if people would let devrel fix its resolution policies 8) (see recent |
14 |
-devrel ml thread) |
15 |
|
16 |
> |
17 |
> As Lance said in an earlier post, infra already does this "temporary |
18 |
> removal of access" if it is an immediate security threat and then |
19 |
> submits the evidence to devrel for followup. Why can't it work exactly |
20 |
> the same for the QA team? If they have done their due diligence by |
21 |
> contacting the dev in question, pointing out their mistakes and offering |
22 |
> assistance to correct the mistakes and the dev just keeps right on |
23 |
> commiting bad stuff QA should be able to "temporarily" stop them until |
24 |
> devrel has a chance to follow up and investigate. That's what QA is, |
25 |
> Quality Assurance, if they have no power to actually "Assure Quality" |
26 |
> then why does this team even exist? |
27 |
> |
28 |
|
29 |
QA and devrel have two different jobs. QA doesn't have to be devrel's |
30 |
problem and devrel tasks don't have to be QA's problem (how much do the |
31 |
QA folks really want to deal with the usual bitchfest when somebody |
32 |
with a lot of friends gets suspended for something?) if they work |
33 |
together on repeated problem developers. |
34 |
|
35 |
> I'll give an example: Saturn car company has a great big red "STOP" |
36 |
> button at every point in the assembly line that can turn off the entire |
37 |
> manufacturing line if QA spots a mistake. The QA team does not have to |
38 |
> ask anyone first, they simply push the button so the low quality car |
39 |
> does not get through, remove the offending car from the line |
40 |
> "temporarily" until a team investigates and decides if the quality is |
41 |
> good enough to put it back on the assembly line. Saturn is known for the |
42 |
> quality of it's cars because of this. The gentoo QA team should have |
43 |
> this same ability. |
44 |
> |
45 |
|
46 |
Does Saturn's stop button also kick the apparently responsible |
47 |
individual out of the building? Otherwise this analogy would work better |
48 |
if applied to ebuilds and the maintainership thereof, not developers and |
49 |
their CVS access. |
50 |
|
51 |
(And on another note, Saturn? Known for quality? Bwahahahah... err. :) ) |
52 |
|
53 |
-- |
54 |
Jon Portnoy |
55 |
avenj/irc.freenode.net |
56 |
-- |
57 |
gentoo-dev@g.o mailing list |