Gentoo Archives: gentoo-project

From: Daniel Robbins <drobbins@××××××.org>
To: gentoo-project@l.g.o
Subject: [gentoo-project] Making Gentoo more fun
Date: Sat, 17 Feb 2018 07:56:40
1 Hi All,
3 I have been reflecting on the recently much-broadcasted conflict between
4 mgorny and zlg, and considering that maybe at the root of it all, we have a
5 process issue rather than a personal one.
7 Consider this -- Gentoo has very little buffer between what is committed to
8 the Portage tree and what ends up on a user's system. Because of this, if
9 you are a senior dev on Gentoo, you can feel some sense of responsibility
10 for breakages that may occur for users. There generate a significant amount
11 of frustration and stress as you try to plug the QA holes that you see
12 appearing before you.
14 This amount of fragility could make one quite anxious, irritable and even
15 bitter towards more junior developers who make mistakes. It could lead to,
16 rather than addressing this underlying problem, potentially being overly
17 harsh with those who make mistakes.
19 I think it may also be leading to placing too much emphasis on making
20 emerge perfect, to the point where it can fix any problem on any user's
21 system, when really this is not realistic -- it is still possible to commit
22 something to the tree that has a bad dependency in it and makes life
23 miserable for users. There's very little that emerge can do to protect
24 users from this -- it just blindly does what the dependencies tell it to do.
26 I've been reflecting on these things because we've instituted a new system
27 in Funtoo that seems to be helping. This is not an attempt to toot my own
28 horn, but I am finally starting to feel a bit of stress relief in this area
29 due to a new process we are using. We have organized the upstream Portage
30 tree into 'kits', or sub-trees, and then we snapshot these sub-trees. Our
31 snapshotted versions are called 'prime' kits, and we will backport security
32 fixes and do cautious version bumping in these kits. But then we work on
33 newer versions of kits to eventually replace the (aging) prime kits, and
34 these are based on newer snapshots from Gentoo. And we also test to make
35 sure that people can upgrade cleanly (no weird dep issues) when
36 transitioning from the older kit to the newer kit.
38 While this interferes somewhat with the "bleeding edge, rolling" model that
39 Gentoo is famous for, it does provide the opportunity to have kits that are
40 stable, not unlike the Gentoo stable branch, except the kits concept
41 provides finer granularity. So for example, you could choose to have a
42 stable core system, but use a more bleeding-edge python or xorg, for
43 example. And I can make sure that things like firmware and certificates
44 always have the latest version.Yes, you can do the same thing with
45 package.unmask, but it is not nearly as clean and modular.
47 Just food for thought -- I am wondering if something similar in Gentoo-land
48 might tackle the root cause of these issues. I know people are here because
49 they care about Gentoo, but we want to make the processes work for
50 developers both new and bearded, and they should allow for some margin of
51 error by developers, because we all make mistakes.
53 I also hate to see what may be a technical/process issue snowball into bad
54 blood between people on the project.
56 Best,
58 Daniel


Subject Author
Re: [gentoo-project] Making Gentoo more fun "Tiziano Müller" <dev-zero@g.o>
Re: [gentoo-project] Making Gentoo more fun Benda Xu <heroxbd@g.o>