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 <gentoo-dev+bounces-33927-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1LJXEH-0006Y6-NJ
for garchives@archives.gentoo.org; Sun, 04 Jan 2009 17:57:37 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id DF24AE06BC;
Sun, 4 Jan 2009 17:57:35 +0000 (UTC)
Received: from mail.goodpoint.de (tori.goodpoint.de [85.10.203.41])
by pigeon.gentoo.org (Postfix) with ESMTP id 92AD9E06BC
for <gentoo-dev@lists.gentoo.org>; Sun, 4 Jan 2009 17:57:35 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
(Authenticated sender: rbu)
by mail.goodpoint.de (Postfix) with ESMTP id 5618B10A006;
Sun, 4 Jan 2009 18:57:34 +0100 (CET)
From: Robert Buchholz <rbu@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
Date: Sun, 4 Jan 2009 18:57:25 +0100
User-Agent: KMail/1.9.9
Cc: Mike Auty <ikelos@gentoo.org>
References: <20081019060114.GA21785@curie-int.orbis-terrarum.net> <20090104180608.2e0935e5@epia.jer-c2.orkz.net> <4960EEA0.6060600@gentoo.org>
In-Reply-To: <4960EEA0.6060600@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed;
boundary="nextPart102598178.3X0SWEa0b6";
protocol="application/pgp-signature";
micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200901041857.28125.rbu@gentoo.org>
X-Archives-Salt: 1c8cba3c-8db5-4df4-8a07-6d92a1ddd83d
X-Archives-Hash: a3b5ae0282ce3e756d19a39c0a92048e
--nextPart102598178.3X0SWEa0b6
Content-Type: text/plain;
charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Sunday 04 January 2009, Mike Auty wrote:
> Jeroen Roovers wrote:
> > The order ("first maintainer as assignee" or "first maintainer/herd
> > as assignee") is open to discussion and I think this is the proper
> > forum to have that discussion.
>
> It seems sensible to me. I would've thought that being more specific
> would surely be better? Splitting them up means those who are mostly
> in charge of a package see it easily, and it's also then easier to
> spot packages that only have a herd, rather than them getting lost in
> all the packages that do have individual maintainers...
>
> I've attached a quick patch that should fix up assign.py to add all
> the herds on the end. Since the order of the second item onwards
> doesn't matter, all herds are added at the end. If we do need an
> ordering (like maintainer1, herd1, maintainer2, maintainer3, herd2)
> then it'll need a more complex patch...
I actually implemented it this way before (only that I had all herds=20
with higher priority than all maintainers, which is the reverse of your=20
patch). The outcome of the previous discussion for me was that there is=20
no real consent on who should be the assignee. Robin put it this way:
On Sunday 19 October 2008, Robin H. Johnson wrote:
> As an addenda, from v1, different teams and developers DO want
> different behaviors:
> 1. Assign to herd, CC all others (eg: GNOME, base-system)
> 2. Assign to first maintainer, CC herd and others (eg: net-mail)
>
> That was deliberately why I had logic about using the order in the
> metadata.xml file, with the addition that later duplicate entries of
> an email would override the first one.
>
> Your generic rule of (assign to first non-herd maintainer, CC rest)
> doesn't fit all of the cases.
Accepting the fact that different teams have different preferences, we=20
need to find a solution for them to set theirs individually. This could=20
either be the order of elements in metadata.xml (and would set the=20
preference on a per-package basis) or some attribute in herds.xml=20
(which would be a global setting per herd, and we'd need to find a=20
default).
Robert
--nextPart102598178.3X0SWEa0b6
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iQIcBAABAgAGBQJJYPiIAAoJECaaHo/OfoM5v38QALJf0gguBCeoNDqkQ0R5mZoC
BNrK5ihfaIRz6+ABjLWxQX5lTtgRi2EBzeoHXSz5LA+nxDd3UMhhe+fwhxE7FwTm
EJnG625rfUjf430eTxus1YvyJznCN5Nq2n2WS9edEnvqoRjFmfmHyMLjrBae14lX
ASD+VsNWfkQ6QZHZCX+ReUZ/RIExZt9Xlaiu4cphyTOcJxwUYhArEKklFWRtibkm
nDmhmXbMfMx9rCTGsfvsFTpk8AYQXAL7t7qAggp8fL0HvoLGWzd3REh7D5Ww2GNp
R8zrBdzLXIeZPnEBsJk1KcddTIbFLPKVzIovPkI+Idng8nUweL5wNf3FWj0nUwGj
1oBYDxUC5qaejfJitTfKenW9pJIfB3JTAubziofFLJXvP639gI0Wt85J0lJ+C9nN
9t0/KtVIQQdmw+tSqDg63Q8LdyJB+CHuLcvN/Ryc2g8b1RzXv2BFJU6DqpB9AdVJ
0uLbFNt3LFvIP7ESktuyKXQR/M/uh9SqH79mzlUNvne8K3YLx6ypa62JhrS3z9sZ
hdrZ8n2+SUugZX5EqJWTE4MN150OMpDgP1EFEFlnVDgLIonrt156mvklYUQYV5g8
pfCPull3XGueHf12fpvaDsYc2sA4FUDVq09NK0kX1Pc1Y9q+rbzoUTRJNPtyRuJ3
8VxVqfDV3PMYYeBYFv00
=tdoa
-----END PGP SIGNATURE-----
--nextPart102598178.3X0SWEa0b6--