From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-project+bounces-4460-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 12952138A1C
for <garchives@archives.gentoo.org>; Fri, 3 Apr 2015 20:01:35 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 9F0D5E09A1;
Fri, 3 Apr 2015 20:01:33 +0000 (UTC)
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 0CF8BE0863
for <gentoo-project@lists.gentoo.org>; Fri, 3 Apr 2015 20:01:33 +0000 (UTC)
Received: by igblo3 with SMTP id lo3so14756682igb.0
for <gentoo-project@lists.gentoo.org>; Fri, 03 Apr 2015 13:01:32 -0700 (PDT)
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=p+A0jTVpCDqPF3d98w168+vRLmwAeX5qFV6NhNbwlU8=;
b=AIRc8qM+9kIwHAW0OFUGA1yvfmeCdFi8c/4J7omlJW0sIFf4BDc72amnifbl2se/M+
d//6hwDcE5CNN/MM7bx8ZkjHZ1a3IgzXMeQBIMhdKdfsbbkEyUycHtZm7oKpxDRvdT+I
NNoQ+8De1rz8D4+4RijC1U6fnCv2rIpy+qDu5KyFiV/NAMxT9hQInf1jit5lNW4jS3UC
OJmlHTqnIgMqeF+HYxDbEWT85ASSilm8QBOfEeOO/RIoQXzc79Dc71XCnFUgDTjAxqIB
jkT703XALILhmIQzAnUHHfqS2F14EZINpPTlBZ8lhWlJNVBbT0mUpRVVmQlo7YolHBvI
axpw==
Precedence: bulk
List-Post: <mailto:gentoo-project@lists.gentoo.org>
List-Help: <mailto:gentoo-project+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-project+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-project+subscribe@lists.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
X-BeenThere: gentoo-project@lists.gentoo.org
Reply-To: gentoo-project@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.50.56.82 with SMTP id y18mr30681550igp.25.1428091292572;
Fri, 03 Apr 2015 13:01:32 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.107.48.198 with HTTP; Fri, 3 Apr 2015 13:01:32 -0700 (PDT)
In-Reply-To: <mfmpto$cis$1@ger.gmane.org>
References: <20150402141428.GA31638@oregano.home.lan>
<mfmpto$cis$1@ger.gmane.org>
Date: Fri, 3 Apr 2015 16:01:32 -0400
X-Google-Sender-Auth: _xIFGoeKDVHGjCbMDd4uTM2oSlI
Message-ID: <CAGfcS_noUvSEcE2B9VnofS2rC0oL7WkUFk1KMYe40-_tu+trqQ@mail.gmail.com>
Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items
From: Rich Freeman <rich@thefreemanclan.net>
To: gentoo-project@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: 33e638c7-c280-4519-8f20-967970cde15d
X-Archives-Hash: f916f9dba6ea73759edfacea275cc7b7
On Fri, Apr 3, 2015 at 3:33 PM, Michael Palimaka <kensington@gentoo.org> wrote:
> On 03/04/15 01:14, Tim Harder wrote:
>> The next council meeting will be on April 14th, 19:00 UTC in
>> #gentoo-council on Freenode.
>>
>> Please respond to this message on the gentoo-project list with any
>> agenda items you want to propose or discuss.
>>
>> Thanks,
>> Tim
>>
>
> Could we please revisit lagging arch teams again? Specifically, I'd like
> to see the package-by-package proposal extended to other minor archs
> including ppc and ppc64.
>
If we're going to bring this up, is sparc a concern for anybody? I
mention it only because it was brought up last time, not because I
have any specific reason to have concerns with them. If we're going
to discuss this again, we might as well be holistic.
For that matter, part of me wonders if this should really be a "minor
arch" policy vs just being general policy, and perhaps we should even
consider doing the same thing with x86/amd64. If for some reason
upstream doesn't support one of those archs or there are no major
issues with moving to the new version, why shouldn't we require arch
teams to stabilize within 90 days even for the big ones?
For reference, the policy we came up with last time for ia64 and alpha only was:
"If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
pending STABLEREQ, for 90 days with archs CCed and otherwise ready
to be stabilized, the maintainer can remove older stable versions of
the package at their discretion. A package is considered ready to be
stabilized if it has been in the tree for 30 days, and has no known
major flaws on arches that upstream considers supported."
The "arches that upstream considers supported" bit seems to make this
fairly suitable for anybody. The intent is to follow upstream, and if
we want to do more then that is on the arch team to make happen unless
the maintainer is willing to do it.
--
Rich