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 9F73F138A6C for ; Wed, 8 Apr 2015 18:15:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2995AE09C8; Wed, 8 Apr 2015 18:15:28 +0000 (UTC) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (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 9E011E089A for ; Wed, 8 Apr 2015 18:15:27 +0000 (UTC) Received: by iggg4 with SMTP id g4so47071587igg.0 for ; Wed, 08 Apr 2015 11:15:27 -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=DNt5bKO0yRKXS7ctyt1ogIg2YHfMDyf9kphudoKK9D4=; b=lbUw8ogS64pdjkMkJwh196/mGdZl+Xsg5sH3yjZ5GNlS4TwW/yvkPdUJOH++xXtHau GhyqWn+S22fX8sgua3/EzGv5+nuA02ibwta+QR/YpS7b4rsUo/q4VBDTxuzAH4/PlmMI mZ6NdBBh1uXeRvIDjMI8rMvvFDk/Pa8z1rRDjCzTphDUyDRJOv6sxUQNsrLf33st6D+z 3QdP+Hj7OfHSvrxUulzqWE8R4ycIDBTZp3U8GkekltZMP/S3Yqu+IlFGG7eFiIjquGs+ eRXL92tbeKXkzsvUnESyH7BiPBN+qrHW/u4GP5/2ZBnZtLAzwg8uH2ckDD8cVzBsjF+e r4AA== 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 X-Received: by 10.43.163.129 with SMTP id mo1mr22861910icc.61.1428516927013; Wed, 08 Apr 2015 11:15:27 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.107.48.198 with HTTP; Wed, 8 Apr 2015 11:15:26 -0700 (PDT) In-Reply-To: <20150408173901.GA11223@linux1> References: <5521BF9C.5060809@gentoo.org> <1428353540.2041.11.camel@gentoo.org> <55246753.5060902@gentoo.org> <20150408115116.GA6220@linux1> <20150408173901.GA11223@linux1> Date: Wed, 8 Apr 2015 14:15:26 -0400 X-Google-Sender-Auth: Ig8nROOKCfiMJXQ-GZixiWWJW24 Message-ID: Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items From: Rich Freeman To: gentoo-project@lists.gentoo.org, Richard Freeman Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 14a90bd8-e1a1-469a-88af-fb791562f395 X-Archives-Hash: 245f931900e3a3bb0bb64a9880e280da On Wed, Apr 8, 2015 at 1:39 PM, William Hubbs wrote: > 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). >> >> 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. >> >> 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. > > 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? No. In neither option would you move foo-1 to ~arch. In neither option would you get repoman complaints. In option 1 you would delete foo-1. Users of the arch will start getting errors when they try to do updates, since foo-2 is keyword masked. Users could just accept ~arch for foo-2 to fix this most likely, though it may not work in some cases. The arch team can clean up the depgraph at some point as well. You don't ever get repoman complaints because the arch is set to dev/exp, and is ignored by repoman. In option 2 you would STILL delete foo-1, and you would also change all of its reverse dependencies to ~arch as well. Users of the arch would get errors when they try to do updates, since many packages they have installed are now keyword masked, and foo-2 is also keyword masked. Users would have to accept ~arch for all those packages to restore normal operation. Later the arch maintainers could restore the depgraph to what it was before while stabilizing foo-2, which involves fixing many packages potentially, and even if it all ends up as stable again users have tons of cruft in their config files. You don't ever get repoman complaints because the depgraph was always consistent. > >> 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. > Option #2 is a NOP in the sense that the Council doesn't have to do anything that has an immediate effect. Basically we'd just be deputizing every maintainer out there to purge keywords on any arch in the list we approve anytime it gets out of hand. So, if an arch has no STABLEREQs older than 90 days today, nothing happens today, but if in six months a glibc STABLEREQ is ignored for 91 days the maintainers can go ahead and remove every single stable keyword on the arch (to pick an extreme example). > 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. The only thing we're required to do as a matter of policy is to show up for a meeting and bang the gavel twice. I don't really like just kicking the can down the street though. If an arch really thinks an extra 30 days will let them become proactive about trimming their keywords I don't mind giving an extension, but I really don't want to end this Council term with maintainers complaining about aging STABLEREQ bugs that they are powerless to do anything about, and I don't think having random maintainers basically treecleaning arches is a great solution either even if it lets us point fingers. I don't see this as picking favorites - x86 is more important than sparc or whatever. All we're doing is just assessing whether an arch team is able to proactively manage their stable keywords or not. If an arch has only a single package marked stable, and they keep up with just that one package, then they can stay stable in repoman. If an arch isn't doing that, then users deserve to know this and understand the implications. It means that at any time stuff that is marked as stable could stop being stable, or could be really out of date. It means that they need to be more careful about the weight they give to a stable keyword. I just see this as being about truth in advertising. Stable keywords are a bit like a contract between package maintainers and arch maintainers. The package maintainers agree to maintain things in a way that keeps the stable experience stable. The arch maintainers agree that in exchange they will keep up with stable requests so that package maintainers aren't dealing with cruft. When the package maintainer violates their end of the deal, QA descends on them. When the arch maintainers violate their end of the deal, the Council marks their arch non-stable. This is a reversible decision. Arch maintainers can control the size of their commitment by not keywording things as stable in the first place, and removing stable keywords when they can't keep up. -- Rich