Gentoo Archives: gentoo-osx

From: Grobian <grobian@g.o>
To: gentoo-osx@l.g.o
Subject: Re: [gentoo-osx] Arch Testing Policy and Procedures
Date: Sun, 04 Sep 2005 10:57:26
Message-Id: 431AD2FE.3020706@gentoo.org
In Reply to: [gentoo-osx] Arch Testing Policy and Procedures by Lina Pezzella
1 Although I like the arch testers (ATs) idea pretty much, I have some
2 questions:
3
4 - Why have the 'low hanging fruit' bugs from before 2005 not been
5 resolved till I run through them a few weeks ago?. Most of them were
6 small and had no USE flags. I expect the devs that had no time to do
7 this in the past won't have time to do it when an AT has run over it.
8 In the end, the dev is responsible for the commit, not the AT, hence I
9 would not be surprised if the dev does a (non USE flag extensive)
10 compilation on his own machine before committing to CVS. A trust
11 relationship between dev and AT is neccessary too and needs to be
12 built.
13 - Maybe AT's should be 'assigned' to one or two devs who are
14 responsible for committing the AT's work. This is a natural mentor
15 relationship as well as QA wise, it is obvious who is going to punish
16 you if your work is not correct ;)
17 - This proposal assumes ATs have time, which devs apparently have not.
18 I agree that the AT work is simple, but boring. Though I still like
19 to know why it hasn't been done in the past.
20 - Assuming I'd have an AT or two assigned to me, I'd like to have the
21 freedom to give them more flesh if they are hungry for it, i.e. dive
22 into why something doesn't configure/build/compile/install and try to
23 come up with a patch. Maybe this is dev dependant, but I think for an
24 AT it would be nice to know there is a road upstairs: if they're good,
25 and do what they do very well, it would be nice if I wouldn't have to
26 commit their work. (in other words: promote such AT to a dev) On the
27 other hand, you still need the AT work to be done.
28
29 I think the draft is a good piece of work. I'm almost eager to have
30 one, like a PhD who gets an MSc assigned to him. My experiences with
31 some bug reporters who were also in IRC to fix bugs using direct
32 feedback from them is very productive, however if I slam myself in the
33 face and throw some cold water over my head I feel myself forced to look
34 at the issue from a much more pessimistic point of view considering this
35 team and the current 'productiveness'.
36
37 Currently, we only discuss the way 'up', but maybe the way 'down' should
38 be in the picture too. An AT should be considered to be 'active'.
39 Where active means that such AT can do some useful work on a regular
40 base. (Note: this implicitly requires devs to be at least as active as
41 the AT.) If not, while there is work enough, such AT should be removed.
42 Might sound obvious, but if there are no hard rules for it, noone will
43 get removed.
44
45 Ok, I better stop this lengthy email right here. Considering the
46 statistics, it's way to long to be entirely read by most people anyway
47 ;) For those that skipped the middle part, a short recap:
48
49 Yes, nice idea, but I think we should look at the problem from inside
50 this very team first. I would consider the average participation level
51 very unhealthy. This team is also very opaque, it's almost impossible
52 to know what someone is working on.
53
54
55 Lina Pezzella wrote:
56 > -----BEGIN PGP SIGNED MESSAGE-----
57 > Hash: SHA1
58 >
59 > Our apologies for the tardiness of this e-mail; we have been preoccupied
60 > with moving back to college this last week.
61 >
62 > We have thrown together some draft documentation[1] regarding our
63 > expectations for ppc-macos arch testers. We have purposely neglected to
64 > include policy and procedures for dealing with stable keywords pending
65 > the current reevaluation of our decision to maintain them. For all
66 > interested, please review the document and tell us what you think. The
67 > faster we can all agree on policy and procedures, the faster we can get
68 > arch testers on board.
69 >
70 > For those that missed the initial arch tester discussion, the hope is
71 > that having a dedicated group of arch testers will improve QA as well as
72 > free up developers to solve design and porting issues rather than
73 > keyword requests and package testing. It is also a great place for
74 > potential new developers to gain experience with the project.
75 >
76 > More policy and procedure documentation to come.
77 >
78 > - --Lina Pezzella && Hasan Khalil
79 > Ebuild & Porting Co-Leads
80 > Gentoo for OS X
81 >
82 > [1] http://dev.gentoo.org/~gongloo/macos/doc/at-procedures.html
83 > -----BEGIN PGP SIGNATURE-----
84 > Version: GnuPG v1.4.2 (Darwin)
85 >
86 > iD8DBQFDGlv7NJ9STR9DbYERAqJ1AKCgQ73vaFfulp1tvXt3FhMOAckZvgCgqO9t
87 > +xaXd/DKXUW0ZmJxomn8vYw=
88 > =GZ6D
89 > -----END PGP SIGNATURE-----
90 > --gentoo-osx@g.o mailing list
91 >
92
93 --
94 Fabian Groffen
95 Gentoo for Mac OS X
96 --
97 gentoo-osx@g.o mailing list

Replies

Subject Author
Re: [gentoo-osx] Arch Testing Policy and Procedures Lina Pezzella <J4rg0n@g.o>