| 1 |
On Sun, 2020-09-13 at 20:31 +0200, Thomas Deutschmann wrote: |
| 2 |
> You maybe all remember what happened to stable-bot: Years ago, |
| 3 |
> kensington created stable-bot on his own as PoC which revolutionized the |
| 4 |
> way how we do package stabilization in bugzilla. The service run on his |
| 5 |
> own infrastructure. Because of the benefit of the service the bot |
| 6 |
> provided, arch team’s workflow became dependent on stable-bot. We were |
| 7 |
> lucky that stable-bot just worked most of the time until the service was |
| 8 |
> down for a while. Nobody was able to help here: Kensigton himself was |
| 9 |
> unavailable, nobody had the sources… the end of the story: mgorny |
| 10 |
> created nattka which replaced stable-bot. |
| 11 |
> |
| 12 |
> However, we are still facing the same problem: |
| 13 |
|
| 14 |
No, we're not. Don't you see the huge difference between proprietary |
| 15 |
closed-source software and free software? |
| 16 |
|
| 17 |
> Only one person is involved in development |
| 18 |
|
| 19 |
How is that a problem? It is quite normal that simple tools are |
| 20 |
developed primarily by one person, and nattka is not exactly rocket |
| 21 |
science. That said, nobody is stopping others from working on it, there |
| 22 |
are surely some improvements to be done. |
| 23 |
|
| 24 |
> and knows how to run it. |
| 25 |
|
| 26 |
Everything is documented and fully contained in puppet. Deploying it to |
| 27 |
new server is as trivial as enabling it on host in question. |
| 28 |
|
| 29 |
> In case something will |
| 30 |
> break again and Michał will be unavailable, we can’t just push a fix and |
| 31 |
> watch a CI pipeline picking up and deploying new nattka. |
| 32 |
|
| 33 |
Who is 'we' here? Our Infra does not use 'CI pipelines', it uses Gentoo |
| 34 |
packages. Deploying a new version means bumping the package, waiting |
| 35 |
for rsync to distribute it (meh!) and telling puppet to upgrade. No |
| 36 |
buzz words involved, sorry. |
| 37 |
|
| 38 |
> Instead someone will have to fork repository from Michał’s private |
| 39 |
> repository at GitHub, make the changes |
| 40 |
|
| 41 |
It's not private, it's public. And to be honest, forking it on GitHub |
| 42 |
will certainly take less time and effort than dealing with |
| 43 |
git.gentoo.org (which needs to happen via Infra). |
| 44 |
|
| 45 |
> and hope that anyone within infrastructure team can |
| 46 |
> help to deploy fixed nattka. |
| 47 |
|
| 48 |
Are you suggesting there is a problem with Gentoo Infrastructure? |
| 49 |
I really don't see where this is going. You're concerned that Infra |
| 50 |
can't handle it, yet you actually ask to make it more reliant |
| 51 |
on Infra... |
| 52 |
|
| 53 |
> This is what the motion is about: This is not about that Gentoo depends |
| 54 |
> on single persons or things like that. It’s about the idea to |
| 55 |
> *formalize* the requirement that any service and software which is |
| 56 |
> critical for Gentoo (think about pkgcore) should live within Gentoo |
| 57 |
> namespace (https://gitweb.gentoo.org/), i.e. be accessible for *any* |
| 58 |
> Gentoo developer and deployments should be based on these repositories. |
| 59 |
|
| 60 |
You should weigh your words more carefully. Otherwise, we're going to |
| 61 |
end up forking the whole base-system, kernel... |
| 62 |
|
| 63 |
> Or in other words: Make sure that we adhere to social contract even for |
| 64 |
> critical software and services Gentoo depends on. So that we will never |
| 65 |
> ever face the situation that something we depend on doesn’t work |
| 66 |
> anymore. |
| 67 |
|
| 68 |
I fail to see how this is going to actually accomplish the goal. Having |
| 69 |
a different pipeline for committing does not make stuff not break, nor |
| 70 |
makes it more likely for people to fix it. In fact, I dare say having |
| 71 |
nattka on GitHub increases the chances of someone (esp. non-developer) |
| 72 |
submitting a fix, compared to obscure git.gentoo.org with no clear |
| 73 |
contribution pipeline. |
| 74 |
|
| 75 |
> Taking care of working pipelines before something is broken |
| 76 |
> should also help us in case something stops working so we don’t have to |
| 77 |
> figure out how to fix and re-deploy when house is already burning (like |
| 78 |
> portage: In case Zac can't do a release for some reason, in theory, |
| 79 |
> every Gentoo developer would be able to roll a new release). |
| 80 |
|
| 81 |
Please tell me how rolling a new release of nattka is exactly harder |
| 82 |
than rolling a release of Portage? I'm pretty sure most of Gentoo |
| 83 |
developers can figure out how to use GitHub, how to fork a repository, |
| 84 |
and if they use Python they can probably deal with pretty standard |
| 85 |
setup.py. Deployment can't be done without Infra's help anyway. |
| 86 |
|
| 87 |
-- |
| 88 |
Best regards, |
| 89 |
Michał Górny |
Archives