From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 90835138BF3 for ; Sat, 15 Feb 2014 15:18:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 65426E0AF9; Sat, 15 Feb 2014 15:18:34 +0000 (UTC) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6AA4DE0AA0 for ; Sat, 15 Feb 2014 15:18:33 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id ie18so10364331vcb.12 for ; Sat, 15 Feb 2014 07:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=BOKtLJOSHh95Uj7dddHkYxozAD7HqsVSDX6oVGHHZg8=; b=Mhp4FnTZeSWmQ068Hs4S7ILIfRIgwRDdGT2RLx3m8BE8UKBKApbKeRdBaiT6zf+0G2 bxezmmH8o4k9zi2h2DPoYcJe6jbNqbQ2QAhvg+iATONCPDR6H56gvBrS0mVWAT0/X33+ DRzEP2DDeNnvPLzo6g/3uoNcFduQWkeHqqJuFwqB6CK2TUqYiMMV2lvoFbmLJLBR1Ul4 27MocEYRR+PK25GGNNZKbJXYfU7FpyXWnXAeEnzgth85DF9SxvS6ofSzTPa68zXbJA9S 8RyhvdZxxs+ZTXR+UlpfrtlqKX0RuVvmvHQ+f1E3Re43zARNOO5+624m5Qn7grxmLM4X K6PA== 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 X-Received: by 10.52.185.196 with SMTP id fe4mr4704443vdc.27.1392477512588; Sat, 15 Feb 2014 07:18:32 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.52.254.198 with HTTP; Sat, 15 Feb 2014 07:18:32 -0800 (PST) In-Reply-To: <20140215143021.231bab3f@marga.jer-c2.orkz.net> References: <52E7DBC1.5020102@gentoo.org> <20140128182304.7d458a17@marga.jer-c2.orkz.net> <20140203062524.GA7467@rathaus.eclipse.co.uk> <20140203104341.2add2760@TOMWIJ-GENTOO> <20140204210319.GA1935@rathaus.eclipse.co.uk> <20140205010833.1bcf8dca@TOMWIJ-GENTOO> <20140213212818.GA2199@rathaus.eclipse.co.uk> <20140214195958.5aea85f0@TOMWIJ-GENTOO> <20140215012855.417f1caa@marga.jer-c2.orkz.net> <20140215114157.6abe3da5@TOMWIJ-GENTOO> <20140215143021.231bab3f@marga.jer-c2.orkz.net> Date: Sat, 15 Feb 2014 10:18:32 -0500 X-Google-Sender-Auth: 0eUX9jcAVD4Lh_aKl7zdBpv5rWc Message-ID: Subject: Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords) From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: e5caf4dc-7a35-4f67-a8b0-98264a86d336 X-Archives-Hash: 3110393688000884eff86f8d968eb631 On Sat, Feb 15, 2014 at 8:30 AM, Jeroen Roovers wrote: > On Sat, 15 Feb 2014 11:41:57 +0100 > Tom Wijsman wrote: > >> While it was not explained here, the idea can also move the actual >> maintenance of the ebuild to the arch team; such that it becomes the >> arch team's responsibility to deal with it, or rather don't deal with >> it > > How would that ever work? You have some old cat/pkg/pkg-version.ebuild > that you no longer want to maintain, but which happens to be the latest > stable for $ARCH, which is apparently understaffed because they $ARCH > hasn't tended to a related bug report in months, and now you want to > leave the ebuild in place and also expect $ARCH to start maintaining > it? How does $ARCH have the man power to do that, again? Many objected to removal since old with minor issues is better than new that doesn't work at all on some archs, or so the argument goes. This thread has gone on for a while, but at least this is a new suggestion. If we were torn between these two options (removal or re-assignment), then we could potentially leave the decision up to the arch team. If they speak up they can get bugs assigned to them, and if they don't speak up they get their stable packages removed. And I'm all for other options, but beyond more manpower I'm just not seeing anything that is going to be pretty. > Nobody is reading those bugzilla e-mails - nobody is working on > keywording/stabilisation for $ARCH. "Nagging" is pointless when > nobody hears you, and an e-mail from bugzilla isn't > magically better prioritised when Assignee: changes. I think the point is that the maintainer doesn't see the nags. If nobody else sees them either it is "somebody else's problem" from their standpoint. That isn't going to make the bug submitter very happy, but if removal of the only version of a package that works on their arch entirely is the alternative I suspect they will live with it, or better still join the arch team. Removing the package version entirely is the tidy solution from a tracking/bugs/etc standpoint. The problem is that for the end user it might mean taking away something that at least somewhat works and leaving them with nothing. Fixing the new version probably isn't an option if somebody isn't willing to step up, so the question is just whether we keep around the old version. The new suggestion is to keep it around, but not to bug the maintainer with the resulting issues. If an old version gets to the point where it is simply unusable it should almost certainly be dropped. That at least avoids constantly pestering the bug wranglers/etc with dups, and gives the arch team a bug list where at least they have some hope of doing something. Rich