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 AE34D1382C5 for ; Sat, 17 Feb 2018 07:56:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9B357E09D4; Sat, 17 Feb 2018 07:56:39 +0000 (UTC) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 63DA0E09D1 for ; Sat, 17 Feb 2018 07:56:39 +0000 (UTC) Received: by mail-io0-x22a.google.com with SMTP id e7so6505247ioj.1 for ; Fri, 16 Feb 2018 23:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=funtoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Ot9tvtL+6O5KmGj31v7aEOiqSoe0hbklp1tUbLAUnmE=; b=Vkxu9u+Ly9bMVgFo4UQcd40PoAk5isc6I5cah2h/AEx5iMdA4QKWuFS5D9rZYOUkWg /3/n+WBrYpq5FBPRp1nQve7m4a5KWiedAyCXc61p+3nZVlQYHhHPgZ/EgZsGeBlrzxYI ufG73YtpTgY3N83Xc+1TduZUGnYc1MdXarz3e6LOusvil9lj8p13eqIIuuEQJ9HPxjYl lgID5rJJxIYFI8cHpVj0zq55RYOrvcYJMWgWwYyykBvRqi2H//cPYxBvZBYD0d4/gI0C 5jscfgfH1cN7ywyr1dmZkVzN63S0EQOB1vbcmebZB56Z0iUHcyC4sFAIQNBI9/jbqIC2 JkEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ot9tvtL+6O5KmGj31v7aEOiqSoe0hbklp1tUbLAUnmE=; b=M6d2ee1z60EKsnPdxNDZ8MMcksTAupAANi3PMxDAMP/LTZtwTw8Af3B5vKCWfOhkPO qh0FZQN+OdfUTNAnoUdX9N9WgRuQvMMIdLvUOb9llDxhv77TXVWMAcBd73mVtQRhncjK BPdZQSuBt3REt65y9U+dV6fUxGJV+IDhZZ+toEZ5g8BnXIHnm2kHy/7+8tTXz2lqixd8 qzma/X+p4TBw902wfTWOlZJCVgbV6BPjGvWL43u8ibVItoL9ZkBGLWwuaf/EPq2EUcz9 LZzYd/rs1dACU/51URADB57t44Ylip/kZJ0GoIgI/nlEMvoXUNR0S9UK2UC1XfxWE0qj xGJw== X-Gm-Message-State: APf1xPDlDOJouLxAJeQpFC+sZsWx1g60/7ZC7/7sx3poisBJKdokQTvN gofSZ04pVgdl77fLh4/w4tyyUBMVRx1MGxc5uySr5VZc X-Google-Smtp-Source: AH8x2264cckNJ72RE9CQg66YE3ZCChU9eBhNCuidL18akubzOt7kxN0hi5QccQ+8AvKywwL7oTUBOF78hutuL2sYMu4= X-Received: by 10.107.107.21 with SMTP id g21mr6901932ioc.208.1518854198021; Fri, 16 Feb 2018 23:56:38 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Received: by 10.79.165.70 with HTTP; Fri, 16 Feb 2018 23:56:37 -0800 (PST) From: Daniel Robbins Date: Sat, 17 Feb 2018 00:56:37 -0700 Message-ID: Subject: [gentoo-project] Making Gentoo more fun To: gentoo-project@lists.gentoo.org Content-Type: multipart/alternative; boundary="089e0825e940f064a7056563cc0c" X-Archives-Salt: 78ad1a75-9744-4977-8c8a-2c9786e4f867 X-Archives-Hash: 0456990515f22efda51feea5f9224c5f --089e0825e940f064a7056563cc0c Content-Type: text/plain; charset="UTF-8" Hi All, I have been reflecting on the recently much-broadcasted conflict between mgorny and zlg, and considering that maybe at the root of it all, we have a process issue rather than a personal one. Consider this -- Gentoo has very little buffer between what is committed to the Portage tree and what ends up on a user's system. Because of this, if you are a senior dev on Gentoo, you can feel some sense of responsibility for breakages that may occur for users. There generate a significant amount of frustration and stress as you try to plug the QA holes that you see appearing before you. This amount of fragility could make one quite anxious, irritable and even bitter towards more junior developers who make mistakes. It could lead to, rather than addressing this underlying problem, potentially being overly harsh with those who make mistakes. I think it may also be leading to placing too much emphasis on making emerge perfect, to the point where it can fix any problem on any user's system, when really this is not realistic -- it is still possible to commit something to the tree that has a bad dependency in it and makes life miserable for users. There's very little that emerge can do to protect users from this -- it just blindly does what the dependencies tell it to do. I've been reflecting on these things because we've instituted a new system in Funtoo that seems to be helping. This is not an attempt to toot my own horn, but I am finally starting to feel a bit of stress relief in this area due to a new process we are using. We have organized the upstream Portage tree into 'kits', or sub-trees, and then we snapshot these sub-trees. Our snapshotted versions are called 'prime' kits, and we will backport security fixes and do cautious version bumping in these kits. But then we work on newer versions of kits to eventually replace the (aging) prime kits, and these are based on newer snapshots from Gentoo. And we also test to make sure that people can upgrade cleanly (no weird dep issues) when transitioning from the older kit to the newer kit. While this interferes somewhat with the "bleeding edge, rolling" model that Gentoo is famous for, it does provide the opportunity to have kits that are stable, not unlike the Gentoo stable branch, except the kits concept provides finer granularity. So for example, you could choose to have a stable core system, but use a more bleeding-edge python or xorg, for example. And I can make sure that things like firmware and certificates always have the latest version.Yes, you can do the same thing with package.unmask, but it is not nearly as clean and modular. Just food for thought -- I am wondering if something similar in Gentoo-land might tackle the root cause of these issues. I know people are here because they care about Gentoo, but we want to make the processes work for developers both new and bearded, and they should allow for some margin of error by developers, because we all make mistakes. I also hate to see what may be a technical/process issue snowball into bad blood between people on the project. Best, Daniel --089e0825e940f064a7056563cc0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I have been reflecting on the r= ecently much-broadcasted conflict between mgorny and zlg, and considering t= hat maybe at the root of it all, we have a process issue rather than a pers= onal one.

Consider this -- Gentoo has very little = buffer between what is committed to the Portage tree and what ends up on a = user's system. Because of this, if you are a senior dev on Gentoo, you = can feel some sense of responsibility for breakages that may occur for user= s. There generate a significant amount of frustration and stress as you try= to plug the QA holes that you see appearing before you.

This amount of fragility could make one quite anxious, irritable and= even bitter towards more junior developers who make mistakes. It could lea= d to, rather than addressing this underlying problem, potentially being ove= rly harsh with those who make mistakes.

I think it= may also be leading to placing too much emphasis on making emerge perfect,= to the point where it can fix any problem on any user's system, when r= eally this is not realistic -- it is still possible to commit something to = the tree that has a bad dependency in it and makes life miserable for users= . There's very little that emerge can do to protect users from this -- = it just blindly does what the dependencies tell it to do.

I've been reflecting on these things because we've institut= ed a new system in Funtoo that seems to be helping. This is not an attempt = to toot my own horn, but I am finally starting to feel a bit of stress reli= ef in this area due to a new process we are using. We have organized the up= stream Portage tree into 'kits', or sub-trees, and then we snapshot= these sub-trees. Our snapshotted versions are called 'prime' kits,= and we will backport security fixes and do cautious version bumping in the= se kits. But then we work on newer versions of kits to eventually replace t= he (aging) prime kits, and these are based on newer snapshots from Gentoo. = And we also test to make sure that people can upgrade cleanly (no weird dep= issues) when transitioning from the older kit to the newer kit.
=
While this interferes somewhat with the "bleeding edge,= rolling" model that Gentoo is famous for, it does provide the opportu= nity to have kits that are stable, not unlike the Gentoo stable branch, exc= ept the kits concept provides finer granularity. So for example, you could = choose to have a stable core system, but use a more bleeding-edge python or= xorg, for example. And I can make sure that things like firmware and certi= ficates always have the latest version.Yes, you can do the same thing with = package.unmask, but it is not nearly as clean and modular.

Just food for thought -- I am wondering if something similar in Ge= ntoo-land might tackle the root cause of these issues. I know people are he= re because they care about Gentoo, but we want to make the processes work f= or developers both new and bearded, and they should allow for some margin o= f error by developers, because we all make mistakes.

I also hate to see what may be a technical/process issue snowball into b= ad blood between people on the project.

Best,

Daniel

--089e0825e940f064a7056563cc0c--