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.54) id 1ExVkd-0001Gs-87 for garchives@archives.gentoo.org; Fri, 13 Jan 2006 20:42:23 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k0DKfq25003652; Fri, 13 Jan 2006 20:41:52 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k0DKfoe9022067 for ; Fri, 13 Jan 2006 20:41:51 GMT Received: from jeeves.egr.msu.edu ([35.9.37.127] helo=egr.msu.edu) by smtp.gentoo.org with esmtp (Exim 4.54) id 1ExVk1-00029W-TU; Fri, 13 Jan 2006 20:41:45 +0000 Received: from [35.9.132.144] (nagoya.dhcp.egr.msu.edu [35.9.132.144]) by egr.msu.edu (8.13.4/8.13.4) with ESMTP id k0DKfkww016584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2006 15:41:47 -0500 (EST) Message-ID: <43C8108B.1030404@egr.msu.edu> Date: Fri, 13 Jan 2006 15:41:47 -0500 From: Alec Joseph Warner User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-qa@gentoo.org Reply-to: gentoo-qa@lists.gentoo.org MIME-Version: 1.0 To: gentoo-qa@lists.gentoo.org, solar@gentoo.org, ferringb@gentoo.org, swegener@gentoo.org Subject: [gentoo-qa] Autorepoman/QA Goals Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: c2dfa748-9b1d-4a34-b1d4-1bfa73f6dd50 X-Archives-Hash: bd54f8fd67e456b00e7ab23889848eec So all 3 of the people subscribed to this list have probably heard this already, but I re-iterate here for those who don't spend their lives staring at IRC backlogs. The current QA team is definately short on overall goals. We have a lot of people that are passionate about QA, and they all do their own thing to contribute. However I think we can do better. So step one is listing QA violations. Sure Repoman complains about most, if not all of them and Mr Bones likes to squish the usurpers that break dependencies in the tree. However I think some of them just pop out at people and they have no clue how to fix them, or the fix isn't easy, or they just don't know how to fix it so they ignore it. Just as was discussed about making people work on Enterprise Gentoo, we can't make poeple do QA who don't necessary care about it. And thats not to say QA isn't important, or whatnot. I think a lot of people view it as a PITA, and so they ignore any problems. Step 2 is improving our QA tool. Sven has written Autorepoman. I have half the code, and partly this mail is to ask Sven to release the other half. Sven, I'd personally like to work on it, I know you have very little time, and it may not be the dream tool you meant it to be. If necessarily I may make an attempt to write my own tool, if you are wary about releasing the code, although I'd prefer not to throw away code you've already written. The current repoman sucks, is not extensible and worse, is within portage itself, bound to their release cycle, which in the past has been pretty slow ( although it should be speeding up ). For now I volunteer maintainership of the tool, primarily because in the 2.1 branch there are a lot of changes and whomever maintains it will probably have to have close ties with the portage team. The main problem with taking repoman out of portage and into QA maintainership is that when devs use ~arch versions of portage, Repoman tends to get castrated by the API changes. Step 3: Posting QA violations publically. By Publically, I mean to the world. We would need a box to run the tool on and generate a webpage, much like autorepoman does now ( although hopefully a bit prettier ). Someone also suggested an internal ( lets it be dev-only or qa-only ) pig tree, that also lists who last touched each file that had a QA violation. This is a toss up but may prove useful ( or foolhardy ) to keep. Step 4: Having a tool to track QA violations, per-dev, per-herd, per-project. I was thinking a record similar to like a GLSA, where we simply record who/what/where/when/why/how and store it somewhere. Then we can run reports on what projects sucked, what projects were good, what devs suck, what devs were good, herds..etc... Step 5: Helping devs help themselves. Most of the things in Repoman's complaint list are automagically fixable. Repoman complains that the ebuild is in cvs but the digest isn't, add the digest to cvs automagically...or ebuild is missing HOMEPAGE, add HOMEPAGE="none", or whatnot. Automation, This goes hand in hand with super sekrit goal #6 Step 6: QA must be Unobtrusive. We were joking in IRC that the title should be "QA we take the fun out of developing." And while funny, thats a bad attitude to have towards the situation. To that end we need to be unobtrusive to developers to gain their support of QA. We need to make good QA easy for devs to accomplish so they aren't hounded by errors every time they commit and say fuck it QA sucks. I think a lot of that has to do with tools that do the work for them, and while some may argue that this will allow bad habits ( Oh I didn't know X was a QA violation because repoman magically fixed it for me every time ), I think partly #1 will mitigate that issue. Lastly of course, we need to come up with a system of punishment to go along with #4, in case a dev/project/herd is having issues keeping up with QA. This is the most difficult issue IMHO, mostly because there arne't a lot of avenues to go down, and DevRel seems quite stagnant recently, although that mail on -dev from fmccor looks promising :) Specifically we probably need some kind of group to review QA records and enforce said punishments themselves, or through devrel as a liason type deal. Lots of stuff, I know solar had some ideas relating to arch teams, I've cc'd a few people because I am not sure if they are subscribed ( sorry if I ended up sending duplicate mails to you three ). -Alec Warner (antarus) -- gentoo-qa@gentoo.org mailing list