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 8698F139694 for ; Tue, 25 Jul 2017 07:22:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EDDF4E0D43; Tue, 25 Jul 2017 07:22:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 95C67E0CB9 for ; Tue, 25 Jul 2017 07:22:32 +0000 (UTC) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: djc) by smtp.gentoo.org (Postfix) with ESMTPSA id A079D34174F for ; Tue, 25 Jul 2017 07:22:31 +0000 (UTC) Received: by mail-lf0-f49.google.com with SMTP id p2so37190281lfg.0 for ; Tue, 25 Jul 2017 00:22:31 -0700 (PDT) X-Gm-Message-State: AIVw112u8Pt1vqsnbXogsfD6Fb4jdyU9U+R/+QJbEbRl0qkNZ9EObmtK V4SDootEFHkjiwBfq3cPs7MGGBmbwQ== X-Received: by 10.25.41.78 with SMTP id p75mr6335242lfp.47.1500967348581; Tue, 25 Jul 2017 00:22:28 -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.215.210 with HTTP; Tue, 25 Jul 2017 00:22:08 -0700 (PDT) In-Reply-To: <20170724222223.6d359e47@sf> References: <20170724222223.6d359e47@sf> From: Dirkjan Ochtman Date: Tue, 25 Jul 2017 09:22:08 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts? To: Gentoo Development Content-Type: multipart/alternative; boundary="001a11410998a1b9c205551f31e8" X-Archives-Salt: e264b302-279d-4be7-a502-d091a84c3216 X-Archives-Hash: bc92ab6e073bc60eeb63496dc1627c08 --001a11410998a1b9c205551f31e8 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 24, 2017 at 11:22 PM, Sergei Trofimovich wrote: > TL;DR;TL;DR: > ------------ > > This email seeks for one step towards less toil tied to gentoo's > keywording/stabilization process. I've CCed a few groups who > might be interested in making this area better: > > - gentoo-dev@ as it affects most devs (and non-devs!) > - wg-stable@ as it overlaps quite a bit with efforts staged on STABLEREQ > (should I join? :) > - arch-leads@ as it directly helps (or breaks everything for) arch teams > - all individual arches for wider visibility > Thanks for kicking off this discussion. As a stable user, this is an important topic to me. Your email is kind of long, and I wonder if we can condense the problem back to simpler first principles. First, the assumption in our processes seems to be that many or important bugs will be due to architecture-specific differences, and I wonder if that assumption really holds up. Do arch testers for a smaller arch often find problems that were not noticed on one of the larger arches? With the languages and tools that we have today, it seems like for many of our packages, bugs due to architectural differences represent a minority of the problems we found. In this case, the whole idea of per-arch stabilization does not really make sense, and doing away with that idea could drastically shortcut our process. Second, I believe a lot of the value in our stable tree comes *just* from the requirement that stabilization is only requested after 30 days without major bugs/changes in the unstable tree. Assuming there are enough users of a package on unstable, that means important bugs can be shaken out before a version hits stable. This could mean that potentially, even if we inverted our entire model to say we "automatically" stabilize after a 30-day period without major bugs, we hit most of the value of the stable tree with again drastically reduced pain/work. Cheers, Dirkjan --001a11410998a1b9c205551f31e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 24, 2017 at 11:22 PM, Sergei Trofimovich <sly= fox@gentoo.org> wrote:
TL;DR;TL;DR:
------------

This email seeks for one step towards less toil tied to gentoo's
keywording/stabilization process. I've CCed a few groups who
might be interested in making this area better:

- gentoo-dev@ as it affects most devs (and non-devs!)
- wg-stable@ as it overlaps quite a bit with efforts staged on STABLEREQ =C2=A0 (should I join? :)
- arch-leads@ as it directly helps (or breaks everything for) arch teams - all individual arches for wider visibility

Thanks for kicking off this discussion. As a stable user, this is an = important topic to me.

Your email is kind of long,= and I wonder if we can condense the problem back to simpler first principl= es.

First, the assumption in our processes seems t= o be that many or important bugs will be due to architecture-specific diffe= rences, and I wonder if that assumption really holds up. Do arch testers fo= r a smaller arch often find problems that were not noticed on one of the la= rger arches? With the languages and tools that we have today, it seems like= for many of our packages, bugs due to architectural differences represent = a minority of the problems we found. In this case, the whole idea of per-ar= ch stabilization does not really make sense, and doing away with that idea = could drastically shortcut our process.

Second, I = believe a lot of the value in our stable tree comes *just* from the require= ment that stabilization is only requested after 30 days without major bugs/= changes in the unstable tree. Assuming there are enough users of a package = on unstable, that means important bugs can be shaken out before a version h= its stable. This could mean that potentially, even if we inverted our entir= e model to say we "automatically" stabilize after a 30-day period= without major bugs, we hit most of the value of the stable tree with again= drastically reduced pain/work.

Cheers,
=
Dirkjan
--001a11410998a1b9c205551f31e8--