Although I like the arch testers (ATs) idea pretty much, I have some
- 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
- 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
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 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
>  http://dev.gentoo.org/~gongloo/macos/doc/at-procedures.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (Darwin)
> -----END PGP SIGNATURE-----
> --firstname.lastname@example.org mailing list
Gentoo for Mac OS X
email@example.com mailing list