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 D0DB7139694 for ; Tue, 25 Jul 2017 13:10:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DFE251FC04C; Tue, 25 Jul 2017 13:10:27 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 9A46E1FC007 for ; Tue, 25 Jul 2017 13:10:27 +0000 (UTC) Received: from [IPv6:2001:44b8:4197:2800:a37a:5ec1:db17:1e49] (2001-44b8-4197-2800-a37a-5ec1-db17-1e49.static.ipv6.internode.on.net [IPv6:2001:44b8:4197:2800:a37a:5ec1:db17:1e49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kensington) by smtp.gentoo.org (Postfix) with ESMTPSA id CB39E341761 for ; Tue, 25 Jul 2017 13:10:25 +0000 (UTC) Subject: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts? References: <20170724222223.6d359e47@sf> To: gentoo-dev@lists.gentoo.org From: Michael Palimaka Message-ID: <10267d25-547b-cbe1-7fdd-40200e7bae4b@gentoo.org> Date: Tue, 25 Jul 2017 23:10:21 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Archives-Salt: b50d3cde-2b59-47e3-91ce-81c17587726f X-Archives-Hash: fcbc56b8ffc5d52777cdf7ce08aff312 On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote: > 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. This would be really interesting to know. > 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. The 30 day waiting period is useful for smoking out major upstream bugs, but can't replace stabilisation integration testing. For example, package foobar may build fine in ~arch but fails in stable because it needs a newer libbaz.