The bigger problem is that those applications are *not* able to easily
be deployed outside of Fedora infrastructure. One consequence of
OpenShift based deployments is that it's become almost too easy to
assume nobody else would ever want to run that code.
Because of this, it becomes hard for community growth around these projects.
I think that's a fair point.
I'm still trying to get Noggin into good shape.
I'm interested in which parts of the Noggin source code make it hard to be deployed outside Fedora. In my opinion those are bugs, because we do want others to be able to deploy it. Do you have some pointers? I'll easily admit we may have gone the easier route by assuming what our infra looks like in a few places, so I'm happy to fix that.
I've been able to evaluate those issues by packaging them as RPMs,
because RPM packaging forces a total decoupling of development,
deployment, and configuration. None of that is true with our container
based deployments. They're not discoverable, and if you can find them,
they're not independently useful.
Hmm, I'm not sure I agree. Containers can be decoupled from the deployment and configuration, can they not? That's how people use all those generic containers on DockerHub, no?
It's probably extra effort to make our containers runnable in different infra, but I'm pretty sure there's also some work involved with making our RPMs buildable/runnable in other distros, no?
So I'm not convinced RPMs are inherently better than containers at that.
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
