On Sun, 2020-09-13 at 20:31 +0200, Thomas Deutschmann wrote: > You maybe all remember what happened to stable-bot: Years ago, > kensington created stable-bot on his own as PoC which revolutionized the > way how we do package stabilization in bugzilla. The service run on his > own infrastructure. Because of the benefit of the service the bot > provided, arch team’s workflow became dependent on stable-bot. We were > lucky that stable-bot just worked most of the time until the service was > down for a while. Nobody was able to help here: Kensigton himself was > unavailable, nobody had the sources… the end of the story: mgorny > created nattka which replaced stable-bot. > > However, we are still facing the same problem:
No, we're not. Don't you see the huge difference between proprietary closed-source software and free software? > Only one person is involved in development How is that a problem? It is quite normal that simple tools are developed primarily by one person, and nattka is not exactly rocket science. That said, nobody is stopping others from working on it, there are surely some improvements to be done. > and knows how to run it. Everything is documented and fully contained in puppet. Deploying it to new server is as trivial as enabling it on host in question. > In case something will > break again and Michał will be unavailable, we can’t just push a fix and > watch a CI pipeline picking up and deploying new nattka. Who is 'we' here? Our Infra does not use 'CI pipelines', it uses Gentoo packages. Deploying a new version means bumping the package, waiting for rsync to distribute it (meh!) and telling puppet to upgrade. No buzz words involved, sorry. > Instead someone will have to fork repository from Michał’s private > repository at GitHub, make the changes It's not private, it's public. And to be honest, forking it on GitHub will certainly take less time and effort than dealing with git.gentoo.org (which needs to happen via Infra). > and hope that anyone within infrastructure team can > help to deploy fixed nattka. Are you suggesting there is a problem with Gentoo Infrastructure? I really don't see where this is going. You're concerned that Infra can't handle it, yet you actually ask to make it more reliant on Infra... > This is what the motion is about: This is not about that Gentoo depends > on single persons or things like that. It’s about the idea to > *formalize* the requirement that any service and software which is > critical for Gentoo (think about pkgcore) should live within Gentoo > namespace (https://gitweb.gentoo.org/), i.e. be accessible for *any* > Gentoo developer and deployments should be based on these repositories. You should weigh your words more carefully. Otherwise, we're going to end up forking the whole base-system, kernel... > Or in other words: Make sure that we adhere to social contract even for > critical software and services Gentoo depends on. So that we will never > ever face the situation that something we depend on doesn’t work > anymore. I fail to see how this is going to actually accomplish the goal. Having a different pipeline for committing does not make stuff not break, nor makes it more likely for people to fix it. In fact, I dare say having nattka on GitHub increases the chances of someone (esp. non-developer) submitting a fix, compared to obscure git.gentoo.org with no clear contribution pipeline. > Taking care of working pipelines before something is broken > should also help us in case something stops working so we don’t have to > figure out how to fix and re-deploy when house is already burning (like > portage: In case Zac can't do a release for some reason, in theory, > every Gentoo developer would be able to roll a new release). Please tell me how rolling a new release of nattka is exactly harder than rolling a release of Portage? I'm pretty sure most of Gentoo developers can figure out how to use GitHub, how to fork a repository, and if they use Python they can probably deal with pretty standard setup.py. Deployment can't be done without Infra's help anyway. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
