* [gentoo-project] Making Gentoo more fun
@ 2018-02-17 7:56 99% Daniel Robbins
0 siblings, 0 replies; 1+ results
From: Daniel Robbins @ 2018-02-17 7:56 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 3106 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3429 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2018-02-17 7:56 99% [gentoo-project] Making Gentoo more fun Daniel Robbins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox