Gentoo Archives: gentoo-dev

From: Jon Portnoy <avenj@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC
Date: Wed, 14 Sep 2005 05:00:07
Message-Id: 20050914045740.GA4006@cerberus.oppresses.us
In Reply to: Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC by Curtis Napier
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

Replies

Subject Author
Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC Curtis Napier <curtis119@g.o>