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 8C80E139694 for ; Mon, 31 Jul 2017 16:51:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D655C1FC11F; Mon, 31 Jul 2017 16:51:53 +0000 (UTC) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (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 78C8D1FC042 for ; Mon, 31 Jul 2017 16:51:53 +0000 (UTC) Received: by mail-lf0-x242.google.com with SMTP id x16so14896022lfb.4 for ; Mon, 31 Jul 2017 09:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=fBfKxU+7hCPAwFvX39i+YN8C2tOwVJjFxL8EhkfNCYc=; b=mrCBbveJMYMJprhFwv+/RsnXJhK0qIu9Yc1kPXmIIMiPQw7sLsIad1t8BDf/TfYEml LX6Owx7RIHeL23dwZJQzUWVpQgapZ+Eb4YxCeY1fjpcLdALlBrdhqqgpAayAMWIJsMF5 xCHzULgCUdNejF+3LKYZYExYDV442HdMKeEIvIBOZRNdNOdWgk9O3O+jIISCeqWWj5rL X+lHyVKVS/dqcgLpRMv+VB3Qk609RqKdOGO1KAEWI1uwL/oy/bhRskvK1jzMSt6SEvo7 5lwd8pQHYpLtsqp9UqyvZDjtML1uoiCxmQXKtiuUritWABNjTAY0ZDr6A3O8a0pEEojc nH8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=fBfKxU+7hCPAwFvX39i+YN8C2tOwVJjFxL8EhkfNCYc=; b=N1uX+xzEbubMGbKCXZV5pSO/pKNpb88QmVN4BzLo1vTD+tW11tWhzmANj390vwpDo5 Sh6vtmHQIO9mdKQOoUkhfTPHm7VLKWJxR8/hfZ6+LVcIz4/qeAvHbBJ4463iUWLoOewY SyMdg8wpoBMIcYdGahNzW0zyFKLo+PDJriyKy/pGqurJvEeX0CG67zmPNR+PZOqkTfQF LyIp0Z9eV6XVzb81vLWU1YfXXZQSwDvqZn/8mt8G4le5Oiq39D1r5QGq4PyQv6VLG7o2 eU0rKX1R4Pjrb8S7cBFofCo2aXME6nXeTzl35lOOtAg0OIW+si/a5yQ9tszA+wD8/hcZ 8w/g== X-Gm-Message-State: AIVw1111jlh/bCFD6AmUKt6ZnpjlHVxvG3GNLAwDk7NNFWoes9CPbvTL QtcIBzfYBeEv1xa46WM3YbSVKadT5Ng7 X-Received: by 10.25.234.20 with SMTP id i20mr6700620lfh.42.1501519911532; Mon, 31 Jul 2017 09:51:51 -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 Received: by 10.25.150.132 with HTTP; Mon, 31 Jul 2017 09:51:29 -0700 (PDT) In-Reply-To: References: <20170724222223.6d359e47@sf> <20170724232244.GT12397@stuge.se> <1931696.H1tAJ0QB7a@porto> From: Peter Volkov Date: Mon, 31 Jul 2017 19:51:29 +0300 Message-ID: Subject: Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts? To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary="94eb2c0c8f54f33e7205559fd89f" X-Archives-Salt: 7bd0589c-478f-4bd8-afa0-842abf105bb0 X-Archives-Hash: 0dd45961305dbd1b2862da35959c6251 --94eb2c0c8f54f33e7205559fd89f Content-Type: text/plain; charset="UTF-8" On Mon, Jul 31, 2017 at 6:11 PM, Rich Freeman wrote: > 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. > Long time ago releng team did something similar. We defined stable as tested distribution that has all security updates merged back. From my experience what made that efforts very tedious was that there were packages that do not specify minimum required versions for dependencies. Thus we had to duplicate maintainer's work and check lot's of dependencies again. Also when we speak about stable tree we first should define what stability are we talking about? What do we guarantee? ABI/API compatibility or that it is expected "just work" (whatever this means)? -- Peter. --94eb2c0c8f54f33e7205559fd89f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 31, 2017 at 6:11 PM, Rich Freeman <rich0@gento= o.org> wrote:
On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner <antarus@gentoo.org> 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 the= y
> want; they can't affect stable at all.
>
> Stable is an entirely separate repo, a fork, where CPVs are pulled fro= m
> Rolling into Stable. If Stable wants to keep a gnarly old version of s= ome
> package around; great! But the rolling people don't have to care.<= br> >

This seems like it would be fairly painful to maintain.=C2=A0 You= 9;d need to
constantly pull in new packages, and prune out old ones.=C2=A0 It would
duplicate many of the functions maintainers already do.=C2=A0 I doubt
anybody would go to the trouble to make this happen.

Long time ago releng team did something similar. We defined stable as= tested distribution that has all security updates merged back. From my exp= erience what made that efforts very tedious was that there were packages th= at do not specify minimum required versions for dependencies. Thus we had t= o duplicate maintainer's work and check lot's of dependencies again= .

Also when we speak about stable tree we first should de= fine what stability are we talking about? What do we guarantee? ABI/API com= patibility or that it is expected "just work" (whatever this mean= s)?

--
Peter.
--94eb2c0c8f54f33e7205559fd89f--