Although I like the arch testers (ATs) idea pretty much, I have some
questions:
- Why have the 'low hanging fruit' bugs from before 2005 not been
resolved till I run through them a few weeks ago?. Most of them were
small and had no USE flags. I expect the devs that had no time to do
this in the past won't have time to do it when an AT has run over it.
In the end, the dev is responsible for the commit, not the AT, hence I
would not be surprised if the dev does a (non USE flag extensive)
compilation on his own machine before committing to CVS. A trust
relationship between dev and AT is neccessary too and needs to be
built.
- Maybe AT's should be 'assigned' to one or two devs who are
responsible for committing the AT's work. This is a natural mentor
relationship as well as QA wise, it is obvious who is going to punish
you if your work is not correct ;)
- This proposal assumes ATs have time, which devs apparently have not.
I agree that the AT work is simple, but boring. Though I still like
to know why it hasn't been done in the past.
- Assuming I'd have an AT or two assigned to me, I'd like to have the
freedom to give them more flesh if they are hungry for it, i.e. dive
into why something doesn't configure/build/compile/install and try to
come up with a patch. Maybe this is dev dependant, but I think for an
AT it would be nice to know there is a road upstairs: if they're good,
and do what they do very well, it would be nice if I wouldn't have to
commit their work. (in other words: promote such AT to a dev) On the
other hand, you still need the AT work to be done.
I think the draft is a good piece of work. I'm almost eager to have
one, like a PhD who gets an MSc assigned to him. My experiences with
some bug reporters who were also in IRC to fix bugs using direct
feedback from them is very productive, however if I slam myself in the
face and throw some cold water over my head I feel myself forced to look
at the issue from a much more pessimistic point of view considering this
team and the current 'productiveness'.
Currently, we only discuss the way 'up', but maybe the way 'down' should
be in the picture too. An AT should be considered to be 'active'.
Where active means that such AT can do some useful work on a regular
base. (Note: this implicitly requires devs to be at least as active as
the AT.) If not, while there is work enough, such AT should be removed.
Might sound obvious, but if there are no hard rules for it, noone will
get removed.
Ok, I better stop this lengthy email right here. Considering the
statistics, it's way to long to be entirely read by most people anyway
;) For those that skipped the middle part, a short recap:
Yes, nice idea, but I think we should look at the problem from inside
this very team first. I would consider the average participation level
very unhealthy. This team is also very opaque, it's almost impossible
to know what someone is working on.
Lina Pezzella wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Our apologies for the tardiness of this e-mail; we have been preoccupied
with moving back to college this last week.
We have thrown together some draft documentation[1] regarding our
expectations for ppc-macos arch testers. We have purposely neglected to
include policy and procedures for dealing with stable keywords pending
the current reevaluation of our decision to maintain them. For all
interested, please review the document and tell us what you think. The
faster we can all agree on policy and procedures, the faster we can get
arch testers on board.
For those that missed the initial arch tester discussion, the hope is
that having a dedicated group of arch testers will improve QA as well as
free up developers to solve design and porting issues rather than
keyword requests and package testing. It is also a great place for
potential new developers to gain experience with the project.
More policy and procedure documentation to come.
- --Lina Pezzella && Hasan Khalil
Ebuild & Porting Co-Leads
Gentoo for OS X
[1] http://dev.gentoo.org/~gongloo/macos/doc/at-procedures.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
iD8DBQFDGlv7NJ9STR9DbYERAqJ1AKCgQ73vaFfulp1tvXt3FhMOAckZvgCgqO9t
+xaXd/DKXUW0ZmJxomn8vYw=
=GZ6D
-----END PGP SIGNATURE-----
[EMAIL PROTECTED] mailing list
--
Fabian Groffen
Gentoo for Mac OS X
--
[email protected] mailing list
