From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9E97713832E for ; Fri, 5 Aug 2016 02:27:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 15AD6E08D5; Fri, 5 Aug 2016 02:27:02 +0000 (UTC) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 72A79E0888 for ; Fri, 5 Aug 2016 02:27:01 +0000 (UTC) Received: by mail-oi0-f43.google.com with SMTP id 4so137182521oih.2 for ; Thu, 04 Aug 2016 19:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=27fUTp9YtkuBo4KLVNrXU1TQS47SSZSoXQsJ9EB1LHw=; b=NDEDpxuN8oIUQ6XFLMhX1FpYVkjYGp7r1cwmE9LsEJvyYmEQf3AtHwAUwS280wrulz qkJe9sRL9ei5YZ0O5g50pMspxVitKHJ0AZN0kbffu8lx5Y7Q0i+WjN2FCeTeU15p8G+7 VYcPRsd+SI8pqaI+fx8IZbK8iZoWrCIHHDGU3+bsNkd8uRd53V5LGUqBQzWYVg1QrVn8 BQBE4H91peXHQuWDd8Q4xoaNIhLQLHGHRhUGmsQ7lAsMtw4yk38o4kAhhiGyZCFJdomY QIm9ofwdyJ6mojLIp5Yc69Cf9RORadv9WztI5JYHQgaTe5ByeDFhdU6uyqZ8Np/rg5Vn +ItA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=27fUTp9YtkuBo4KLVNrXU1TQS47SSZSoXQsJ9EB1LHw=; b=ZlX/FucUKmEC9i7nS84R9AnamJV48W3c2qNQ8m7lr28/jng/hPjzju5LzHqCr19Rj9 k3OkctVw+c4sK4acoYDGxxUNiG93bSLC0WlmYafep0qdjPQrlqwl+JV5jTpkL3hj8WlC TnexRwZssET3/X8jrXawlWXcJDzZP+s74tcvpoN+OwfhQNkFCSPZOjTJGr04VrFBLsgr gM4Q51Rh6QmswZu0eO08sWkDyamauYj+98m0yKPuFdFNTCApQCYynF33A6MVfSgnWrWA co1hw6d4eg1CwPFmh7EnpoR4cZJI2X0t4pHx1bxUn7eoYslWwmC/lCRmKOB0oLR0Sow3 Hyqg== X-Gm-Message-State: AEkoouvQjYTsRug8PD3XHarT3Q6G/mUHXnkoQ5nSBm/n0NFNmfjQL9Y3+BklAFzNzK1bwQ== X-Received: by 10.157.52.188 with SMTP id g57mr14814788otc.173.1470364019948; Thu, 04 Aug 2016 19:26:59 -0700 (PDT) Received: from linux1 (cpe-66-68-34-247.austin.res.rr.com. [66.68.34.247]) by smtp.gmail.com with ESMTPSA id q77sm240176ota.0.2016.08.04.19.26.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Aug 2016 19:26:59 -0700 (PDT) Sender: William Hubbs Received: (nullmailer pid 15888 invoked by uid 1000); Fri, 05 Aug 2016 02:26:58 -0000 Date: Thu, 4 Aug 2016 21:26:58 -0500 From: William Hubbs To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 Message-ID: <20160805022658.GA15727@linux1> Mail-Followup-To: gentoo-project@lists.gentoo.org References: <2e11e445-c25b-b7f2-def1-99aed92308b6@gentoo.org> <20160804162443.GA7048@whubbs1.gaikai.biz> <20160804231224.7b7462168f1d23e88fe4135c@gentoo.org> <20160804222234.GA8357@whubbs1.gaikai.biz> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list 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="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Archives-Salt: 6b28f717-8e13-415b-a609-4e4e3996bbeb X-Archives-Hash: 68a6f1ed9529b7be36fd355c0f11f694 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 04, 2016 at 07:25:52PM -0400, Rich Freeman wrote: > On Thu, Aug 4, 2016 at 6:22 PM, William Hubbs wrote: *snip* > > > > My proposal is saying that if you have a version of a package in ~, > > testing is being done, and at the end of the testing period (30 days at > > most), that new version in ~ should move to stable if there are no > > blockers. It would be up to you, the maintainer, or any users running > > the ~ version, to test and file bugs that block stabilization. These > > bugs could be detected automatically. > > >=20 > I'm mostly fine with that, but I'd add just a requirement that > somebody does a quick sanity check on an otherwise-stable system. The > 30 days of testing is really only testing against dependencies that > are in ~arch. Granted, that will become less of a concern if all > those dependencies are also making their way to stable. =20 Repoman will complain loudly if you try to stabilize something that doesn't have all of its reverse dependencies stabilized, so I think we are safe as long as people listen to repoman. I'm not advocating stabilizing things with ~ reverse dependencies, just trying to find a way to move stabilization along better than it has been moving. *snip* > > > > We basically do. I don't have a link in front of me, but the council > > did make a decision allowing the removal of packages from the stable > > tree. It hasn't played out well though, because stable users expect > > that once a package is in the stable tree it will stay there until a > > newer version comes to the stable tree. >=20 > I'd have to look up the exact decision, but it was basically left to > maintainer discretion after some time lag. I think it is a useful > safety valve. If the maintainer feels that the stable version is > de-facto unmaintained and is causing problems, then we're not doing > stable users any favors by just leaving it on their systems. Just go > ahead and drop it and stable users can stick it in an overlay if they > know what they're doing, but they won't just live with some unknown > issue. =20 If we can get the newer version stabilized, we can then remove the older version without breaking stable, so this then becomes a non-issue. Also, getting the newer version stabilized is a more favorable approach because you don't have to deal with breaking the depgraph, or in the case of a package that is in the stages, if you remove the stable version, you can break the stages for that arch. *snip* > > > > 2. if the package is all data files, or if it is written in an > > interpreted language e.g. python, perl, etc., Once the testing period > > has passed, the maintainer will be allowed to stabilize it on all arches > > that have a stable version without a stable request. >=20 > I believe there is already widespread agreement on this point. We've > talked about mechanisms to designate these packages but if we just > want to go with maintainer discretion we might be fine. Well, let me back up a bit on this one. We have the allarches keyword which can be added to a stable request to let the first arch team know to stabilize on all listed arches. Maybe we should forget option 2, and just say that if a package version is = in ~ with a stable request opened for more than 30 days with all of its reverse dependencies stable the maintainer can stabilize that version of the package on all arches that have a stable version. William --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlej+WwACgkQblQW9DDEZTje7wCfTP68I9eGY3psW6j2lBLZ8L74 BTEAoJNHs/lmYoO339pLAQ8c/zNHb7o5 =uFri -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO--