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 1LKTOv-0002sT-3R for garchives@archives.gentoo.org; Wed, 07 Jan 2009 08:04:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8D68BE0326; Wed, 7 Jan 2009 08:04:14 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 083D7E0326 for ; Wed, 7 Jan 2009 08:04:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8B7F06414A for ; Wed, 7 Jan 2009 08:04:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 required=5.5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJeVMXrliWmD for ; Wed, 7 Jan 2009 08:04:05 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 5054E64590 for ; Wed, 7 Jan 2009 08:04:03 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LKTOS-0006C5-DC for gentoo-dev@gentoo.org; Wed, 07 Jan 2009 08:04:00 +0000 Received: from 91.85.129.122 ([91.85.129.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Jan 2009 08:04:00 +0000 Received: from slong by 91.85.129.122 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Jan 2009 08:04:00 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: [v4] Planning for automatic assignment computation of bugs Date: Wed, 07 Jan 2009 07:53:34 +0000 Message-ID: References: <20081019060114.GA21785@curie-int.orbis-terrarum.net> <20090104180608.2e0935e5@epia.jer-c2.orkz.net> <4960EEA0.6060600@gentoo.org> <200901041857.28125.rbu@gentoo.org> <1231236674.5292.122.camel@localhost> 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 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.85.129.122 User-Agent: KNode/0.10.9 Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 4a834155-46ec-4edf-ac8e-3f7461e5b361 X-Archives-Hash: b22505492ae66ea3ebf1274a1924d181 Peter Volkov wrote: > ? ???, 04/01/2009 ? 18:57 +0100, Robert Buchholz ?????: >> Accepting the fact that different teams have different preferences, we >> need to find a solution for them to set theirs individually. This coul= d >> either be the order of elements in metadata.xml (and would set the >> preference on a per-package basis) or some attribute in herds.xml >> (which would be a global setting per herd, and we'd need to find a >> default). >=20 > It looks like we really need some per-team configuration for default > assignment. I agree, given that it's not going to affect running systems (I hope); in the longer term, it would be nice to be able to configure by pkg, cat or herd. > Probably it's good idea to add 'weight' (or 'nice')=20 > attribute for and elements both in herds.xml and > metadata.xml. Bug assignment field will be selected from the elements > with minimal weight (least nice ;)). Shouldn't the 'nicest' entity take it? ;) A simple assignToHerd=3D"yes|no|" (or 0|1) might be easier to deal= with (otherwise you're going to have a maintenance headache with the variant levels?) and would deal with all the use-cases afaict; a team does [eg kde/gnome] or does not want bugs, unless the category/CP/CPV merits a change in that policy. Obviously if none set, use the maintainer list as-= is without filtering. Sure, it can be done by patching the tree over time, but it seems crude a= nd a further maintenance + bug-wrangling burden for no benefit, when the coders are on-hand and engaged to tweak the new impl. OFC, a rush to completion is understandable, given how long this has been= in the planning; I'd argue that's a reason to go the final ten metres.