Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
Date: Mon, 14 Sep 2020 14:15:50
In Reply to: Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace by Kent Fredric
1 On Sun, Sep 13, 2020 at 11:52 PM Kent Fredric <kentnl@g.o> wrote:
2 >
3 > But when you file a bug, you rely on bugzilla being maintained by
4 > Gentoo Infra, not some 3rd party.
5 >
7 I think the Council will need to consider where it wants to draw the
8 lines on something like this. Here is my sense of how these sorts of
9 things come about:
11 1. Somebody sees an opportunity for improvement and writes some code.
12 They interface it on their own with git/bugzilla/whatever and host it
13 on their own systems. They use it for a while and improve it.
15 2. They start to advertise it and call for testers. This is nothing
16 more than a list post at the start. It is completely optional. A few
17 people start using it and find that it is helpful.
19 3. It is still optional, but since it is helpful the 10% of the devs
20 who do 90% of the work in the relevant area (like arch teams/etc)
21 adopt it, which means that 90% of the work is using the new tool,
22 still self-hosted by the dev. It might or might not have any source
23 published.
25 4. The devs who are using the tool are also the ones maintaining all
26 the documentation for the official workflows, and they update it to
27 reflect what they're actually doing. It might still be optional. (In
28 fact, as far as I can tell from reading the docs nattka is still
29 optional - you could still just CC arch teams and so on yourself -
30 heck, arch teams can stabilize things even if you don't file a bug
31 though this is unlikely to happen much.)
33 5. At some point somebody notices that 80% of the problems come from
34 the 10% of the work that isn't doing things the new way, and the new
35 way stops being optional.
37 Maybe somebody closer to these tools might want to correct something
38 above. However, as an observer this is how these things seem to
39 evolve - it is a very bazaar-like methodology.
41 Keep in mind that rules don't make things happen - they prevent things
42 from happening. The hope behind a rule is that if you dam off
43 something suboptimal the enthusiasm travels down some other path and
44 doesn't just die off. So, where do you build the dam above? Do you
45 let steps 1-4 happen and draw the line at step 5, which might just
46 mean that we accept the 80% of the problems that come from it being
47 optional until infra hosts it? Do we draw the line all the way up at
48 1 and block any use of APIs in ways that are not explicitly approved?
49 Do we block it at step 4, so the arch team is using nattka for 90% of
50 the cases, and they just trade notes via email and nobody else knows
51 what they're doing because the wiki reflects a process nobody actually
52 follows?
54 I realize that I'm mostly pointing out things that can go wrong.
56 I don't think anybody would say that it is better not having infra
57 maintaining critical infra. The problem is that the infra team
58 probably isn't going to officially host stuff way back at step 1. A
59 random dev can't write a script and ask infra to start running it and
60 bug them 3 times a day to do a pull from their git repo. Infra is
61 probably going to wait until something closer to step 3-4 before they
62 get involved, which means the tool is already being used for a
63 substantial amount of work. I'm not sure if we even have a defined
64 process for getting new tools like these onto infra, or how we do
65 config/change management in these cases.
67 The council can say "don't use non-infra-hosted services as part of
68 essential processes" but what does that actually mean? Does that mean
69 going up to step 3, so 90% of your arch testing bugs are going through
70 nattka, but it just isn't documented on the wiki? Does it mean going
71 up to step 2, so some portion of them are - if so how do you prevent
72 it from going from 10% to 90% if the new tool works better? Does it
73 mean not interfering at all with 1-5 but imploring infra and the
74 service maintainers to figure something out? If the service isn't
75 expensive to run, those maintaining the service might not see much
76 benefit in moving it over, and infra is of course always
77 manpower-constrained.
79 It might be easier to take smaller steps, such as having a policy that
80 "any call for devs to use/test a new tool/service, or any service that
81 automatically performs transactions on bugzilla, must be FOSS, and the
82 link to the source must be included in the initial communication, and
83 it must be clear what version of the code is operating at any time."
84 That is a pretty low barrier to those creating tools, though it
85 doesn't address the infra concern. However, it does mean that infra
86 is now free to fork the service at any time, and reduces the bus
87 factor greatly.
89 --
90 Rich