From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1EBsBh-0005oe-Sj for garchives@archives.gentoo.org; Sun, 04 Sep 2005 10:57:26 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j84As7ND016410; Sun, 4 Sep 2005 10:54:07 GMT Received: from hermes.orakel.ods.org (dsl67-66.fastxdsl.nl [62.251.66.67]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j84As7I9017378 for ; Sun, 4 Sep 2005 10:54:07 GMT Received: from aphrodite.orakel.ods.org ([172.17.2.15]) by hermes.orakel.ods.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1EBsBK-0007BH-I0 for gentoo-osx@lists.gentoo.org; Sun, 04 Sep 2005 12:57:04 +0200 Message-ID: <431AD2FE.3020706@gentoo.org> Date: Sun, 04 Sep 2005 12:57:02 +0200 From: Grobian Organization: Gentoo Foundation User-Agent: Thunderbird 1.0+ (Macintosh/20050813) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-osx@gentoo.org Reply-to: gentoo-osx@lists.gentoo.org MIME-Version: 1.0 To: gentoo-osx@lists.gentoo.org Subject: Re: [gentoo-osx] Arch Testing Policy and Procedures References: <87387351-FB42-4D57-8602-8FFC0794DE40@gentoo.org> In-Reply-To: <87387351-FB42-4D57-8602-8FFC0794DE40@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Scanned: by hermes.orakel.ods.org (Exim Exiscan) using SpamAssassin and ClamAV X-Archives-Salt: ed9278e2-f23b-4e18-9a95-f00f6cdec174 X-Archives-Hash: 30fdad3790088d83f044ebeab07df550 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----- > --gentoo-osx@gentoo.org mailing list > -- Fabian Groffen Gentoo for Mac OS X -- gentoo-osx@gentoo.org mailing list