1 |
Hi All, |
2 |
|
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. |
6 |
|
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. |
13 |
|
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. |
18 |
|
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. |
25 |
|
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. |
37 |
|
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. |
46 |
|
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. |
52 |
|
53 |
I also hate to see what may be a technical/process issue snowball into bad |
54 |
blood between people on the project. |
55 |
|
56 |
Best, |
57 |
|
58 |
Daniel |