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 3A0BC139694 for ; Tue, 1 Aug 2017 00:55:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 206E01FC09F; Tue, 1 Aug 2017 00:55:08 +0000 (UTC) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 CB24E1FC06D for ; Tue, 1 Aug 2017 00:55:07 +0000 (UTC) Received: by mail-yw0-x22b.google.com with SMTP id l82so1064792ywc.2 for ; Mon, 31 Jul 2017 17:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=I3c/r55Rw4ttDcmcMR00KUjpqcA9gpgxwRUqk3G+O14=; b=RsudTz/I7M2E8e04fT7sA1hyg2jg7HDk/NDeohBJh8wdj/bj52/7P2Omz3l6x/u8ja l4Kf0N71yz+Sl0kXMKMquSVk3NOiCEx/Yx8Thu7axt6O8bDbBbhjaChHOEZ5SH2qh+zQ dRzp3Nzp5iEbFDCSbdh3QwSBmq897MHTdD31OWpMHWiaG/+5pgxvMYrG33epftVAnNdc NCttf+fF31NC5e+CxAxUV+d8MLZNbdc6mC4M3coLKJzBIxt027SuF/JxRYI0koAKKoYa N/npnn8fjFTZbTPP4owH8h4nnFpHed6ivDwf9KbR56DcjNXl/uiyRwCzVZmvDp1nX2NB oSVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=I3c/r55Rw4ttDcmcMR00KUjpqcA9gpgxwRUqk3G+O14=; b=SwMWXDgm86oBO7Bez6LdFL4HyS+VhAXtMYt6/vfRDaIfD3Pc3sxJQF+MOh3jKlhj5f 84ppuhNLttq3rTQBr9dV7/yPuTyZbdMC3QvgQq34gd71i1Ii2IdKQLSGOm1bD2al4kli IM8/D+i/R8da5gX50V1Fb6ugbd17T2BGsDf/Tl9fv+SgRqI0o90YNE/k+yWcyoG25rHg 0iDcoiIzaMgZE4B7x1I5Cy0UUOAAL5BFy0AtynrVDdpfImZWrFMq9zFmYjue9PofQQXO Mb3f3X4DYUq1R4mJ34pkdRLWJeeYyigS8AqPNVGj9rAXuC5GqAAJPHMD/wVKFbmIMuBK v/Gg== X-Gm-Message-State: AIVw112/w88aDJvjFWh70CRIt4AzrdkNNt+okme4OJ6Y6ktroaXrSYsd GvI5ZDqwrngCQIzwgo0blDQDsiAh3VxU X-Received: by 10.129.117.65 with SMTP id q62mr14978660ywc.448.1501548906122; Mon, 31 Jul 2017 17:55:06 -0700 (PDT) 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 Sender: freemanrich@gmail.com Received: by 10.129.71.3 with HTTP; Mon, 31 Jul 2017 17:55:05 -0700 (PDT) In-Reply-To: References: <20170724222223.6d359e47@sf> <20170724232244.GT12397@stuge.se> <1931696.H1tAJ0QB7a@porto> From: Rich Freeman Date: Mon, 31 Jul 2017 20:55:05 -0400 X-Google-Sender-Auth: LEL81DvYyGykl3TuzNHIJ6dLllE Message-ID: Subject: Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts? To: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 9b380950-8738-4f4a-848f-7b23e72b2a53 X-Archives-Hash: fb55fceb2a4274bde9392dbaae720691 On Mon, Jul 31, 2017 at 8:24 PM, Duncan <1i5t5.duncan@cox.net> wrote: > Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted: > >> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner >> wrote: >>> >>> >>> Sorry, to be clear the conclusion I was hoping to draw is that one has >>> 2 repos instead of 1. >>> >>> 1) Rolling. >>> 2) Stable. >>> >>> Rolling is typical ~arch Gentoo. People in rolling can do whatever they >>> want; they can't affect stable at all. >>> >>> Stable is an entirely separate repo, a fork, where CPVs are pulled from >>> Rolling into Stable. If Stable wants to keep a gnarly old version of >>> some package around; great! But the rolling people don't have to care. >>> >>> >> This seems like it would be fairly painful to maintain. You'd need to >> constantly pull in new packages, and prune out old ones. It would >> duplicate many of the functions maintainers already do. I doubt anybody >> would go to the trouble to make this happen. > > FWIW, the gentoo/kde team effectively do this right now, tho only with kde > packages and some of their deps, and it's live/prerelease/release-staging > vs ~arch/stable, not ~arch vs stable. But the amount of work is surely > similar, and they've been doing it now for a number of years and over a > major kde version bump, an upstream svn/git upgrade and general upstream > remodularization. > The difficulty isn't in moving the ebuilds around. The difficulty is in knowing WHICH ebuilds to move around. In the case of KDE it is the maintainers doing the maintaining, so they already understand which versions should move. They've all been tested, so I suspect it is likely a lift and place of the entire thing. In the proposed multi-repository approach the maintainers would not be the ones doing the moving. Now, I guess you could have a snapshot/release-based approach. Take a snapshot of the ENTIRE ~arch tree. Then do whatever level of QA, and after a delay move the ENTIRE ~arch tree to stable. The problem with this is that you'll probably pick that oddball version of some package that is about to be replaced and isn't a good stable candidate, and so on. It also would be difficult to actually test it all. And if you're going to get the maintainers to move all their own stuff, then you're just giving them extra work compared to just using the KEYWORDS variable. In the current state the maintainer is at the heart of the stabilization process, so the person who already needs to understand the individual package is the one deciding which versions go stable. Duplicating this level of knowledge would not be straightforward. -- Rich