From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI, RDNS_NONE autolearn=no autolearn_force=no version=4.0.0 Received: from crunch.banyandesign.com (unknown [209.12.56.114]) by chiba.3jane.net (Postfix) with ESMTP id E260FABD52; Fri, 19 Apr 2002 21:16:01 -0500 (CDT) Received: from gentoo.org (adsl-157-146-171.gnv.bellsouth.net [66.157.146.171]) by crunch.banyandesign.com (8.10.0/8.10.0) with ESMTP id g3K24cE20676; Fri, 19 Apr 2002 22:04:42 -0400 Message-ID: <3CC0CF44.8050303@gentoo.org> Date: Fri, 19 Apr 2002 22:15:32 -0400 From: William McArthur User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020413 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gentoo Dev Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [gentoo-dev] Improving stability - checkpoints Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 3049d2dd-5474-4a05-898e-d6b054315ef1 X-Archives-Hash: 63c22989f105cf9ad345455822098b27 [Sorry if this is a duplicate, I'm currently demonstrating a severe lack of email skills.] The other day there was a discussion on IRC about improving the stability of the distro as a whole. The popular idea at the time was a stability metric applied to each package based on a few things. The following is my thoughts on how to improve the situation with minimal developer effort. First, I don't think the stability metric idea won't have it's desired effect. The libpng problems would not be prevented with a stability metric. The problem was not with the package specificlly but the interaction between pacakges. Specifically packages that linked with libpng and expected libpng-1.0.* . We need something to describe a stable system as a whole. There are other sumissions out there but I'm unconvinced that they would improve stability. I propose something I've dubbed a checkpoint as a feature to be added to emerge and a step in our developement process. Every other month or so we have a package freeze where we create a new checkpoint. Checkpoint file(s) describe the reasonably stable leading edge of each package currently available. Then during this freeze we test pacakges, the interaction between packages and the upgrade process. Checkpoints are not like the package.mask because they don't exclude packages and don't prevent the user from upgrading package past what is listed in the checkpoint file. They describe the newest packages that `emerge foo` or `emerge --update world` will upgrade to. The user is still free to specify a newer version manually if for some reason they want to. Think of them as a line in the sand where everything on one side is considered reasonably stable and tested. I envision a tool, it could be part of emerge, that is like the java-config's --list-available-vms and --set-system-vm= arguments. The tool handles the selection of the current checkpoint file. For example: ============ $ emerge --list-checkpoints x86-bleeding-edge x86-curent-stable x86-2002-apr x86-2002-feb Checkpoint is currently set to: x86-2002-feb $ emerge --set-checkpoint=x86-2002-apr Checkpoint is now set to: x86-2002-apr ============ The bleeding-edge and current-stable checkpoints are special. Bleeding-edge is effictivly no checkpoint at all, or always the newest packages. Current-stable is like a sym-link to the most recent checkpoint and is automatically updated when a new checkpoint is final. In the above example that would be x86-2002-apr. Checkpoint files should not be changed once deemed final. Thus they should be written so to allow a little wiggle room for bugfixes, probably only within different releases of the same ebuild version. This makes good use of a developers time beacuse they aren't chasing bugs due to all the variations of various pacages they didn't test. Many users will like not having to compile every point release of a package that is needed by some package they are merging. This is a duplicate benefit of the world favorits and I think obsletes it. Many more users will like the reduced risk of 'emerge --update world' leaving their system in a b0rken state. Users that want the bleeding edge can still have it by specifing a package version or the bleeding edge checkpoint file. Checkpoints would only be considered supported until they are two or three checkpoints old. I hope this makes sense. I'm having trouble keeping my thoughts straight and this is the second time I've written this due to a system crash. As always, feed back is desired. Sandy McArthur