From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-project+bounces-4501-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 354B0138A6C
for <garchives@archives.gentoo.org>; Wed, 8 Apr 2015 17:39:04 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id C8856E09D1;
Wed, 8 Apr 2015 17:39:03 +0000 (UTC)
Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173])
(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 0B4A8E097E
for <gentoo-project@lists.gentoo.org>; Wed, 8 Apr 2015 17:39:03 +0000 (UTC)
Received: by obbeb7 with SMTP id eb7so74077720obb.3
for <gentoo-project@lists.gentoo.org>; Wed, 08 Apr 2015 10:39:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=sender:date:from:to:cc:subject:message-id:mail-followup-to
:references:mime-version:content-type:content-disposition
:in-reply-to:user-agent;
bh=I3CHi6+LTYnOSEDXSUQLOO+EQ9dTM3gdynWbYadZI4U=;
b=x3f6xc8baUWfD7S858M9OetShfu1iyEkD0WdIDxPO00/UTvhQMbb2n0miwMznTEC2y
AUaJcdLuOXiwUinpSdkYYpzcVHTEb9mqpYqwiRe5j0mzNSN3WnjYE8AHmuh2KpCXtDcj
HcQHZcAHy+BQ3FI/ijHEE5k6zPGD2ku6rha7C8mG6Zg2Axcu3cHm2gHf+7vEDoVoQ68s
9OP/59QcsH2TExMhNqAQ+za+bqTUt+lF47YnFM77xDnX/nU5hlQU8ERNSVwIGeqF5OVz
EQR2hXTbXp+c3rmgFlJPt6evFEeoPUyVLJ9vtUSsMCMtdwOocV+DWZ5MJEQnROPstfTj
xl6A==
X-Received: by 10.60.101.195 with SMTP id fi3mr33602757oeb.65.1428514742331;
Wed, 08 Apr 2015 10:39:02 -0700 (PDT)
Received: from linux1 (cpe-76-187-91-128.tx.res.rr.com. [76.187.91.128])
by mx.google.com with ESMTPSA id oy11sm9257629oeb.3.2015.04.08.10.39.01
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 08 Apr 2015 10:39:01 -0700 (PDT)
Sender: William Hubbs <w.d.hubbs@gmail.com>
Received: (nullmailer pid 11390 invoked by uid 1000);
Wed, 08 Apr 2015 17:39:01 -0000
Date: Wed, 8 Apr 2015 12:39:01 -0500
From: William Hubbs <williamh@gentoo.org>
To: gentoo-project@lists.gentoo.org
Cc: rich0@gentoo.org
Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda
items
Message-ID: <20150408173901.GA11223@linux1>
Mail-Followup-To: gentoo-project@lists.gentoo.org, rich0@gentoo.org
References: <CAGfcS_=jmcpD9+Dr5iPxxaCwhwJTPkrsW1xnKRVPLYMt48WVMg@mail.gmail.com>
<5521BF9C.5060809@gentoo.org>
<CAGfcS_k=6X-zc-koYZ4dmjkajZZLZt+3-n3n9Vv_4UUbNMwHsw@mail.gmail.com>
<1428353540.2041.11.camel@gentoo.org>
<CAEdQ38E1qaw61TOhvuPHYKmjSnY9g0UFqPSDKBRKtBOa-2_v2g@mail.gmail.com>
<mg0tli$cq1$1@ger.gmane.org>
<55246753.5060902@gentoo.org>
<CAGfcS_=yj2SFuujU24=yxTtv1DnuQH9ecfH2EJWEY=beRvmqDQ@mail.gmail.com>
<20150408115116.GA6220@linux1>
<CAGfcS_np+Ngr0MgpsesFDXeexbu-mJVtU=b6e6rmEfquZnikJw@mail.gmail.com>
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
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX"
Content-Disposition: inline
In-Reply-To: <CAGfcS_np+Ngr0MgpsesFDXeexbu-mJVtU=b6e6rmEfquZnikJw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Archives-Salt: 92dfc54b-45a5-4321-b33b-102daeb7f92f
X-Archives-Hash: c39fa448285a962b5fd5f03101e06743
--huq684BweRXVnRxX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Apr 08, 2015 at 09:33:39AM -0400, Rich Freeman wrote:
> Well, we really have a few options as far as imposing changes from
> outside the arch team goes (the arch team can clean up its own
> depgraph, of course, but presumably we'd be taking action only if they
> didn't).
>=20
> 1. We could make the arches dev/exp as you point out, and then allow
> maintainers to just drop stable versions and break their depgraph.
>=20
> 2. We could keep the arches as stable, but then allow maintainers to
> do massive keyword changes when they drop otherwise-stable versions.
> That wouldn't break the depgraph, but it would mean that at random
> times huge numbers of packages could have their keywords change.
=20
It seems like the only difference between these two options would be
who is responsible for fixing the depgraph. Let me say why I'm thinking
this.
Suppose that foo-1 is stable everywhere and I'm looking at a stable
request for foo-2. I'm passed 90 days since I assigned the arch teams to
this stable request. Also, foo is unslotted.
Removing foo-1, or moving it back to ~arch, is going to have the same affect
for all arches where it was stable and foo-2 is not, so I'm thinking I
may as well remove foo-1.
The difference, for stable vs non-stable arches, is that I will get
complaints from repoman when I remove foo-1 for stable arches and I
should also fix those.
Is this right?
> Neither option is really ideal. I think that #1 is the lesser evil,
> but that does mean that we need to make a distro-wide decision. The
> advantage of #2 is that it basically is a NOP unless the arch team
> actually reaches 90 days old. I think it is better to just have the
> Council make a decision rather than kicking the can, but that said if
> an arch team is willing to state clearly that they intend to
> proactively clean up their depgraph and that they want to keep stable
> keywords, I'm fine with checking back in a month rather than
> de-stabilizing them next week.
Option #2 really isn't a NOP. It would say that maintainers have
permission to remove old stable versions of a package when arch teams
take more than 90 days to respond to a stable request for a newer
version of the package.
Also, do we have to make a distro-wide decision about whether an arch is
stable? I realize we have been the ones making those decisions, but I
don't think there is a policy that requires us to.
William
--huq684BweRXVnRxX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlUlZ7UACgkQblQW9DDEZThqZACgtZTsr69ViMwN+wYWrNxIPakD
A1kAmwYPZWXjOC+Kuv/+fg+UJuyL4xN+
=tjXN
-----END PGP SIGNATURE-----
--huq684BweRXVnRxX--