From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JVQwZ-0000NU-28 for garchives@archives.gentoo.org; Sat, 01 Mar 2008 12:35:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9B60FE0698; Sat, 1 Mar 2008 12:35:57 +0000 (UTC) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by pigeon.gentoo.org (Postfix) with ESMTP id 823F7E0698 for ; Sat, 1 Mar 2008 12:35:57 +0000 (UTC) Received: from gw.thefreemanclan.net ([71.242.211.138]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JX1009W6XNMHIP5@vms046.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Sat, 01 Mar 2008 06:35:47 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id 7DB301240CA for ; Sat, 01 Mar 2008 07:35:46 -0500 (EST) Date: Sat, 01 Mar 2008 07:35:46 -0500 From: Richard Freeman Subject: Re: [gentoo-dev] Monthly Gentoo Council Reminder for March In-reply-to: <47C9360A.9080806@gentoo.org> To: gentoo-dev@lists.gentoo.org Message-id: <47C94DA2.5090802@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <20080301103002.A2AE266A22@smtp.gentoo.org> <47C9360A.9080806@gentoo.org> User-Agent: Thunderbird 2.0.0.9 (X11/20071116) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 8152fa91-3cd5-48ec-91d7-6ecc00852e42 X-Archives-Hash: f7c0f65df8ddebe9e8f6c19509200917 Ra=FAl Porcel wrote: >=20 > So it would be cool if they accepted help from other devs who don't hav= e=20 > an amd64 system but have access to one and can test stuff. Cla is=20 > willing to help. >=20 I think this may be more a question of what our policy should be=20 regarding level of testing/stability accepted. I'm sure manpower is a=20 factor as well (number of devs isn't necessarily directly proportional=20 to number of hours spent by those devs per week on gentoo). I don't keyword a package stable unless I've done at least a moderate=20 amount of testing on the package to ensure that it works. If a package=20 looks simple but obscure I might go ahead and install it and play with=20 it, but I'd probably never keyword an emacs package stable, since I=20 don't ever use emacs and I won't pretend that all there is to it is=20 installing it and typing "hello world" and figuring out how to quit. Also, the more critical a package is the less likely I am to keyword it=20 without care - I'm not going to keyword apache stable unless I've=20 installed it and put several of my php/cgi-perl apps through a fair=20 number of chores since I know that people who run apache generally care=20 that it works. If there are folks out there who can test on amd64 systems then I'm sure=20 that the amd64 team would look forward to their help (just contact=20 kingtaco about it) - either by arch testing or perhaps by just=20 keywording as appropriate. However, we do need to be careful about just=20 going on a hunt to close bugs - "if it builds then it's stable" isn't=20 really a policy I think we want to follow. As an amd64 user as well as=20 a dev I know that I'd rather be a little further behind on package foo=20 (with the ability to accept ~amd64 on it if I wanted to) than to have=20 packages breaking every other week because somebody keyworded them just=20 because it compiled and didn't have any glaring faults. I think we also need better coordination across gentoo regarding when=20 packages should be stabilized. I've seen amd64 CC'ed on stablereq bugs=20 filed by end users, and arch teams keywording them left and right, and=20 there is no sign that the package maintainer wants the package=20 stabilized. I know that I'd be annoyed if arch teams stabilized a=20 package that I maintained and I didn't intend for it to become stable=20 for whatever reason. At the very least maintainers should be contacted=20 before packages go stable - and they should probably document their=20 intent in STABLEREQ bugs before everybody goes crazy closing them out. I think that if we have the right policies then we'll be where we want=20 to be. Personally, it doesn't concern me a great deal that there are=20 tons of bugs open on an arch in and of itself (although blockers and=20 security bugs are a different matter). I'd rather that then keyword=20 something stable anytime one person (usually not the maintainer) asks us=20 to. And users who feel like they're being held up should feel free to=20 ping a dev to talk about it - and comments by users and maintainers in=20 bugs indicating how stable a package really is make people like me more=20 warm and fuzzy about keywording it without as much personal testing. --=20 gentoo-dev@lists.gentoo.org mailing list