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
In Reply to: [gentoo-osx] Arch Testing Policy and Procedures by Lina Pezzella
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 
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] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (Darwin) > > iD8DBQFDGlv7NJ9STR9DbYERAqJ1AKCgQ73vaFfulp1tvXt3FhMOAckZvgCgqO9t > +xaXd/DKXUW0ZmJxomn8vYw= > =GZ6D > -----END PGP SIGNATURE----- > --gentoo-osx@g.o mailing list >
-- Fabian Groffen Gentoo for Mac OS X -- gentoo-osx@g.o mailing list


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