On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > Good Morning, > > We posted this [1] blog today and want to open a mailing thread to garner > feedback, field questions and get some thoughts from the Community on > the approach that we in Community Platform Engineering (CPE) are taking. > > [1] https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/ > Two things that concern me at this time: > Mailman/Hyperkitty/postorious — Maintaining this stack has cost the equivalent > of an entire developer’s time long-term. However, we recognize the imperative > that projects have mailing lists for discussion and collaboration. No further > features will be added here and based on the community needs an outside > mailing list service can be contracted. I really don’t think this is true anymore. It *is* annoying that the packaging is still *not* in Fedora, so other people can’t help with making sure that software stays up to date, but this should be fixable. I’m happy to co-maintain packages in Fedora+EPEL for mailman3, hyperkitty, and postorius. However, no one has submitted the latter two for review. The mailman 3 stack is starting to see broader adoption. I’ve seen a number of RH and non-RH projects alike deploy and use it. It’s slow, but it’s growing in use. They’re not even hard to find if you know some Google-fu. “An outside mailing list service can be contracted” doesn’t make any sense for a project that does close to 70% of its communication via mailing lists. This does not make sense at all, and I would say this should move from category 3 to category 2 *at least*. Again, I’m personally willing to help with keeping the software packages up to date provided someone puts in the initial effort to get them into Fedora + EPEL. I know the packaging exists and is being maintained externally somewhere, so it should be no challenge to upstream them into Fedora. > Ipsilon — Ipsilon is our identity provider. It supports multiple > authentication protocol (OpenID 2.0, OpenID Connect, SAML 2.0, …) > and multiple backends (FAS, LDAP/FreeIPA, htpasswd, system accounts…). > While it was originally shipped as a tech preview in RHEL it no longer is and > the team working on this application has also been refocused on other projects. > We would like to move all our applications to use OpenID Connect or SAML 2.0 > (instead of OpenID 2.0 with (custom) extensions) and replace FAS with an > IPA-based solution, which in turn allows us to replace ipsilon by a more > maintained solution, likely Red Hat Single Sign On. The dependencies > are making this a long term effort. We will need to announce to the community > that this means we will shut down the public OpenID 2.0 endpoints, > which means that any community services that use this protocol need > to be moved to OpenID Connect as well. There are two issues to unpack here: 1. We use a weird custom backend and custom protocol extensions. This should definitely be replaced if it makes sense. It’s more urgent now that RHEL 6 is going EOL next year, and FAS 2 is still a Python 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS developers died a while ago… Naturally, the replacement is equally in a poor state, but may have some legs someday: https://github.com/fedora-infra/noggin 2. Ipsilon development was only considered important as part of being tech preview in RHEL and now it’s not. There are some major problems here. First of all, Ipsilon development has been gated by a single person. That person also seems to have trouble making time to review pull requests. There has been interest from the broader community about using and contributing to Ipsilon, since unlike Keycloak, it is written in an accessible language (Python). Getting Ipsilon to Python 3 would be enough for me to get started on bootstrapping some of the other interested parties onto Ipsilon, and hopefully give us a more sustainable community long-term. A final note here, I’m generally disappointed in how inaccessible infrastructure resources are to the broader community, and while a community OpenShift will alleviate some of that, I’m concerned that more sophisticated services would still require the crap workflow we have now for community vs infra. I’ve had thoughts about how to make that better on a broader basis, but that’s probably for another time… -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
