On Mon, Jul 22, 2019 at 06:59:04PM +0300, Alexander Bokovoy wrote: > On ma, 22 heinä 2019, Jeremy Cline wrote: > > On Sun, Jul 21, 2019 at 05:37:10PM -0400, Neal Gompa wrote: > > > Keycloak is not generally Fedora contributor friendly. Aside from it > > > being written in Java (which is problematic with the Java stack in > > > Fedora slowly imploding...), Keycloak is a lot less flexible and a lot > > > more tied to aspects of RHEL/Fedora that make it annoying to use in > > > other environments. > > > > This sounds more like an issue with Fedora's Java stack. I don't love > > Java anymore than anyone else (I think), but I really don't understand > > why a language plays such a huge role. > > It is mostly due to supportability of the packages in Fedora. Java > products tend to be split into smaller packages and an overhead for > maintaining them grows a lot. In 2019 Fedora Java packages got dropped > by one of maintainers and that created a havoc as many packages depend > on few important ones that were suddenly not supported anymore and were > going to be orphaned. The same is, I think, true of many other languages. I think it's a sign that our approach to packaging is going to have to change. Just looking at the package stats by language at https://libraries.io/ and comparing it to the size of the Fedora repositories is telling. > > Keycloak is actually quite more flexible in terms what it provides and > how it could be integrated than Ipsilon but it is oriented to be > integrated within applications so that both user experience and visual > experience are integrated end-to-end. In most cases that means use of > the same ecosystem (Java-based) which doesn't play well with > semi-isolated non-Java Fedora project applications we are talking about > here. That's unfortunate, but I wonder how hard it would be to work with Keycloak to make our use-case easier. Would it really be harder than maintaining our own application for the rest of time? > > > > At least with Ipsilon, the Python codebase makes it easy for a broad > > > base of contributors to hack on the code. It's also much easier to set > > > up than Keycloak and easier to plug into more environments. > > > > I imagine Keycloak wouldn't be against making their project easier to > > set up and plug into other environments, but maybe I'm wrong. > > It is relatively easy to set up by itself. However, here we are coming > to a traditional dichotomy on what is easy for RPM-based environment and > what is easy for Java-based deployments. These two environments aren't > necessarily at conflict but traditions in both camps are widely > different. > > > > > > > > > The biggest issue with Ipsilon as a project is the lack of awareness > > > of its existence. That has allowed the fact that the maintainer hasn't > > > recently been able to focus on it in a while to be unnoticed. Now that > > > is changing, and this is a problem, as I outline later... > > > > > > > For Fedora, though, if FreeIPA can replace FAS, or GitLab can replace > > > > Pagure, or a generic notification service exists somewhere to replace > > > > FMN, or whatever, why spend time on such things we could be spending > > > > developing the few unique tools we need to continue building the Fedora > > > > distribution? Stopping along the way to build an identity and access > > > > management platform isn't going to make the distribution better. > > > > > > > > > > FreeIPA is a perfectly fine solution, since it's broadly available and > > > easy to deploy. The non-Java parts (everything but Dogtag) is quite > > > easy to understand and hack on. Reproducing the tooling and > > > environment is easy as well. I have no problems with it other than > > > FAS-specific functions still need implementing on top of FreeIPA > > > (which in theory, Noggin will do). It's more complicated than I'd like > > > in some ways, but at least setup is replicable, making it easy to do > > > development and contribute. > > > > > > As for GitLab vs Pagure, my reasoning is more or less than same as > > > mine with Keycloak vs Ipsilon. And there *are* users other than us for > > > both Pagure and Ipsilon. > > > > Ruby is just Python without () and a lot of question marks in function > > names. Making a code review tool + issue tracker + story board + CI > > pipeline is an insanely difficult, complicated task. Far harder than > > learning Ruby properly. > > > > I don't mean this as an attack on any of the maintainers or contributors > > to Pagure, just feedback. It is not pleasant to use. Not for code > > review, not for issue tracking, not for CI. Other platforms (several of > > them open source) are far, far better in every area and at this time I > > wouldn't ever choose to put a project on Pagure. > > > > The opportunity cost of spending developer time trying to get Pagure > > functional is enormous. The cost of system administrator time is huge. > > Perhaps most importantly, it sucks up huge amounts of user time when > > it's broken/down/slow/non-functional. > > > > In my opinion Fedora is spinning its wheels here, and the vehicle isn't > > even pointed in the right direction. Gnome is on GitLab. Debian and the > > graphics stack is moving to GitLab AFAIK. We could be working towards > > making their development environment better along with our own by > > contributing to GitLab, or we can continue to work on a similar project > > with a tiny fraction of the resources and cost users vast amounts of > > time. > > It all depends on what are you using it for. I'm not satisfied with > GitLab performance we see with Samba Team merge requests workflow. > GitLab UI is very slow there, for example, literally hanging up very > recent Firefox if you need to look at results of executed pipelines. Sure, I don't think GitLab is perfect and it has its pain-points. Working with upstream to make it better for all the communities using it seems like a much better way to spend our collective time, though. > > > > The difference between Ipsilon and Pagure, in my view, is the primary > > > maintainer. Pierre-Yves Chibon has been very accessible and a pleasure > > > to work with as part of contributing to Pagure. I have virtually no > > > experience interacting with Patrick Uiterwijk because he's barely > > > around. > > > > I agree that Patrick is wildly over-worked. He's around everywhere, but > > the problem is there's so much stuff there's just not enough of him to > > go around and he deserves to be able to go on PTO or spend his evenings > > relaxing rather that putting out fires all over Fedora. > > We all feel the same. If Patrick is not enough, the answer should really > be not just in reducing the set of apps to maintain. It should also be > looked at another angle -- may be we need to have more Patricks. (This > is said by the guy who is also overworked on FreeIPA side). Yeah, I don't disagree, but I also don't have a good solution for pulling in a bunch more people to do the work. > > > > We have a number of projects that we're basically said only the > > > "security guy" can work on (i.e. Patrick). That's more of a problem > > > than anything else the CPE team does. The bus factor of *one* security > > > person is ridiculous, and the fact we're stretching him across both > > > CentOS and Fedora now means he doesn't pay enough attention to either > > > project. If we're going to have this (frankly insane) requirement that > > > we need to block all this on a security person, we need more than one. > > > Full stop. > > > > More resources would be great, yes. When I was on the infrastructure > > team I felt we needed orders of magnitude more developers and system > > admins for what we were doing. The thing is, though, Fedora's not going > > to get that many more resources. I don't expect Red Hat to open more > > positions for Fedora, and I know that the community is a very limited > > resource. > > > > That's why Fedora needs to stop re-inventing every single thing it > > needs. We don't have the resources and pretending we do is damaging the > > contributor experience. > > My experience with those other tools, like GitLab, is that as soon as > you are going to solve the problems Fedora infra is facing, with those > tools, you are going to find issues everywhere and will have to > contribute to fixes to projects that might not be willing to accept > them. For various reasons, but would you have a plan how to handle that? Yes, this is always a problem and it was not my intention to imply that we'll just install upstream and use it for src.fedoraproject.org. It's inevitable that there will be patches and upstream will be reluctant to take some of them. I'd suggest we do what we do all over the place: carry patches as necessary. It sucks, and rebasing is non-trivial work, but I would argue it's not nearly as much work as rebuilding everything from scratch. That's like forking a project, but deleting all the code you forked before you begin. - Jeremy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
