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 8EB92138247 for ; Wed, 15 Jan 2014 21:42:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D6035E0BC4; Wed, 15 Jan 2014 21:42:34 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CC830E0B84 for ; Wed, 15 Jan 2014 21:42:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 0290833F2A1 for ; Wed, 15 Jan 2014 21:42:33 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5.5 tests=[AWL=-1.142, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.123, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TAO1oBVRGHR for ; Wed, 15 Jan 2014 21:42:27 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id CF44533F62B for ; Wed, 15 Jan 2014 21:42:26 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W3YE8-0002Wc-AN for gentoo-dev@gentoo.org; Wed, 15 Jan 2014 22:42:20 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Jan 2014 22:42:20 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Jan 2014 22:42:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: rfc: revisiting our stabilization policy Date: Wed, 15 Jan 2014 21:41:55 +0000 (UTC) Message-ID: References: <20140114213719.GA2684@laptop.home> <20140115105415.5df3cdac@pomiot.lan> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 6daf184 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 7c4450e5-3840-4f53-96a6-3a64ec8e21c0 X-Archives-Hash: f4fb0a7d880cb1bccbe2b47d28d87f36 Rich Freeman posted on Wed, 15 Jan 2014 07:51:49 -0500 as excerpted: > Given constrained manpower the options basically are some variation on: > 1. Status quo - for some packages stable gets REALLY old, and likely has > problems that maintainers ignore. You can't force somebody to maintain > something any more than you can force somebody to test something. > > 2. We become more liberal with stabilizing newer versions. Lots of > variations on this, but the bottom line is that packages get stabilized > that would otherwise not be. > > 3. We drop stable keywords on packages. Lots of variations on this as > well, but the result is mixed-arch systems or dropping stable for the > whole arch. > > I don't think #1 is really the answer - it just results in less-visible > problems and a stable that is probably works worse than either #2 or #3 > would yield. > > #2 has the advantage that it gives us more control over what gets > installed on stable systems and you don't end up with mixed keywords. > The downside to #2 is that the user doesn't have as much visibility into > which packages are "really" stable. Maybe an in-between quality tier > would help (if you're going to run a mixed keyword system, at least use > this version). What about a third "target-stable" keyword? Either arch-teams or package- maintainers (with maintainers getting priority in case of differing viewpoints, just as arch-teams already have priority over full-stable) could set this, and it would let users who wanted to be "almost stable but hasn't gotten thru all the hoops just yet" arch-testers do just that, see and test almost-stable packages. An open stabilization bug would be required for any target-stable package, and only one target-stable per-slot per-arch would be allowed -- if there's already a target-stable in that slot for that arch, it would need to be removed and either that package fully stabilized or the new one substituted in the target-stable slot. * Note however that different archs could however have different target- stable packages within a slot. This would allow a maintainer to set a minimal version target-stable keyword for lagging archs, while setting a preferred version target-stable keyword for current archs. A maintainer facing lagging archs could then set target-stable appropriately, and could re-assign any bugs on the old-stable version to the arch in question, with comment boilerplate to the effect that the arch is lagging and hasn't updated stable, so they get to deal with bugs for their ancient-stable version. A variant on the theme would be to split the current stable keyword in half, arch-stable and maintainer stable. Any package version keyworded for both would be considered fully stable, but the two halves would then be fully independent, no longer interlocked, and for half-stable packages bugs would be assigned to the stable side with the other side CCed. In this variant, there'd be no limit on the number of package versions that could be half-stabled by either half, just as there can now be multiple stable-keyworded versions, and for that matter, multiple testing versions as well. > #3 has the advantage that it makes the problem directly visible to the > user. However, the solution ends up being entirely user-discretion. Either target-stable keyword variant above would be directly visible to the end user as well, and of course they could choose full-stable or half- stable on either side as they wished. > Some users end up on ~arch for life, others do it version-by-version in > which case they end up on various versions. Personally I run stable and > when I need to run unstable on a package I tend to use syntax so that I'm tracking unstable until the next major version and > then I get a chance to revisit the decision - usually stable catches > up by then. Interesting. Nominally I do ~arch as for me stab?le== , but I do more or less the same thing at the overlay-~arch/unkeyworded/masked/live-9999 level. For my kde packages, for example, I run the overlay and normally package.keyword/package.unmask 4.y.9999 as soon as it's available in the kde overlay (I have scripts that do git log --color --stat --graph $branch ORIG_HEAD.. on the overlays, and routinely run them after syncing so I know what's going on). But since upstream kde doesn't split a branch until the rcs and thus those branches and the kde overlay packages based on them don't appear for the betas, I have to switch to -9999 during the kde betas, and "downgrade" back to 4.y.9999 when upstream branches and the 4.y.9999 ebuilds appear. I suppose one of these days I'll setup kde-frameworks and be doing about the same for it, too... What's nice is that for kde 4.12.9999 for example, when gentoo/kde was still sorting out the masking/dependencies issues in the overlay due to plasma/workspace being locked to 4.11.x, I was able to grab the 4.11.9999 unmask files from the overlay, do a global search and replace 4.12.9999 in place of 4.11.9999 but keeping the 4.11.9999 for workspace packages, set a few KDE_OVERRIDE_MINIMAL=4.11 via package.env, and go to town with 4.12.9999 before gentoo/kde had finished sorting out the masking and dependency issues themselves. =:^) Of course for kde there's the -4.x.9999 versions to use. For openrc, etc, there's not. There it's -9999 or ~arch, and for openrc in particular I use -9999 because the ~arch ebuild changelogs simply aren't detailed enough and it's too difficult to track down the bugs when they inevitably appear. Git log and if the commit log is interesting enough, git show , is far *FAR* better! =:^) Unfortunately, while it might have been useful for devs, git-r3 has sure been a headache for users trying to follow upstream development with git log ORIG_HEAD.. There's workarounds, but they're a lot more hassle with git-r3 than git2 was. =:^( -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman