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