On ma, 22 heinä 2019, Jeremy Cline wrote:
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.
That or those language libraries' repositories would need to evolve too.
After all, not all of them have strong authenticity guarantees and
ability to account for changes on a local installation.
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?
I don't think it would be hard. However, it needs coordination between
people from both problem domains. Here we exactly getting the issue CPE
tries to address: lack of resources to coordinate such kind of work.
I'm more interested in seeing how Keycloak and other Java-based
applications and libraries can be turned into more optimal payloads with
the help of Quarkus.io. This should eliminate majority of
performance/memory consumption discussions that were limiting reuse of
them outside Java ecosystem.
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.
Probably. My practical worry here is that Fedora Project needs might
come at clash with Open Core approach of GitLab where we would be
working on something that is in the non-free core of GitLab. Many
enterprise features are fitting there.
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.
I think there is a logical mistake in the above statement because we
aren't starting from scratch here. We have pagure.io and ipsilon and a
lot of other applications already. They have a lot of deployments that
proved themselves.
What we faced with is a bit where adding new features to them means a
need to find new contributors to share the load. But I see this
happening with all 'old' technologies and code bases. As someone who
witnessed first-hand how Samba TNG fork went twenty years ago, I don't
hold any hopes for success by forking of a complex project. Instead, it
has to be a careful work on nurturing new contributors, with a mix of an
investment and opening up collaboration.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
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
