Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 31, 2019 at 7:17 AM Pierre-Yves Chibon wrote: > > On Tue, Jul 30, 2019 at 01:13:50PM -0400, Tim Zabel wrote: > >Hello, > >I'm a little late to this conversation, but is fpaste in Category 4 due > > to > >the high legal costs, or because of a lack of a maintainer? > >It would be sad to see fpaste go away because of legal reasons. Is there > > a > >better way to handle this? > > Basically both, it has a very high legal cost and the software we use is not > maintained and hasn't been for a while. Finding a new pastebin that works, > means > investigating the ecosystem, figuring out which one fits best our needs, > getting > it deployed, monitoring the project for security issues and alike. > All this considered, CPE feels that spending time on fpaste isn't the best use > of its time, especially considering the number of nicer pastebins out there. Hi, For a pastebin replacement I can point you to my colleague's filebin [1] project that is our $DAYJOB dogfood. It's written in Go and might need work to be included in Fedora. I can only promise to help as an ambassador to make sure any request or contribution from Fedora gets attention. Dridi [1] https://github.com/espebra/filebin/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 31 Jul 2019 at 09:17, Pierre-Yves Chibon wrote: > > On Tue, Jul 30, 2019 at 01:13:50PM -0400, Tim Zabel wrote: > >Hello, > >I'm a little late to this conversation, but is fpaste in Category 4 due > > to > >the high legal costs, or because of a lack of a maintainer? > >It would be sad to see fpaste go away because of legal reasons. Is there > > a > >better way to handle this? > > Basically both, it has a very high legal cost and the software we use is not > maintained and hasn't been for a while. Finding a new pastebin that works, > means > investigating the ecosystem, figuring out which one fits best our needs, > getting > it deployed, monitoring the project for security issues and alike. > All this considered, CPE feels that spending time on fpaste isn't the best use > of its time, especially considering the number of nicer pastebins out there. > I think to be clear we are talking about the paste service hosted here (https://paste.fedoraproject.org/) and not the fpaste cli tool. The cli tool is not maintained by the CPE team and the cli tool can be changed to use a different service. We are planning to coordinate with the fpaste maintainer to insure that the cli was migrated to another service before we shut down paste.fp.o. Clément > Best, > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Tue, Jul 30, 2019 at 01:13:50PM -0400, Tim Zabel wrote: >Hello, >I'm a little late to this conversation, but is fpaste in Category 4 due to >the high legal costs, or because of a lack of a maintainer? >It would be sad to see fpaste go away because of legal reasons. Is there a >better way to handle this? Basically both, it has a very high legal cost and the software we use is not maintained and hasn't been for a while. Finding a new pastebin that works, means investigating the ecosystem, figuring out which one fits best our needs, getting it deployed, monitoring the project for security issues and alike. All this considered, CPE feels that spending time on fpaste isn't the best use of its time, especially considering the number of nicer pastebins out there. Best, Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
Hello, I'm a little late to this conversation, but is fpaste in Category 4 due to the high legal costs, or because of a lack of a maintainer? It would be sad to see fpaste go away because of legal reasons. Is there a better way to handle this? - Tim Zabel On Tue, Jul 23, 2019 at 5:12 PM Adam Williamson wrote: > On Tue, 2019-07-23 at 09:32 +0300, Alexander Bokovoy wrote: > > > > > 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. > > Not just that. AIUI, there are significant issues with scaling for > Pagure. It wasn't really initially designed to be very scalable, so now > we have bigger and bigger instances of it and more and more people > throwing in pull requests and issues and things, it's getting pretty > creaky. Pingou and Patrick are working on this, AIUI, but it's not an > *easy* problem to solve. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Tue, 2019-07-23 at 09:32 +0300, Alexander Bokovoy wrote: > > > 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. Not just that. AIUI, there are significant issues with scaling for Pagure. It wasn't really initially designed to be very scalable, so now we have bigger and bigger instances of it and more and more people throwing in pull requests and issues and things, it's getting pretty creaky. Pingou and Patrick are working on this, AIUI, but it's not an *easy* problem to solve. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
* Nicolas Mailhot via devel [23/07/2019 11:51] : > > That is not true. Search the list archive for Michael Zhang’s questions on > how to get Open Liberty in Fedora. About 4 months later, can anyone do a dnf > install open liberty, pointing to a Fedora repo? No but that's probably because he got several comments on his review request and hasn't replied to them (his last comment on the bug[1] was in February). Emmanu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On 7/23/19 4:18 AM, Neal Gompa wrote: Also, for $DAYJOB, I run a GitLab server. If you think maintaining a GitLab server is easy, you have another think coming. For what it's worth: I'm afraid I have to agree. I've been running Gitlab for my employer for the last 18 months. It's *incredibly* labor-intensive. There are lots of bugs. Things change in unexpected ways which creates a lot of user tickets. There's no published documentation on sharding, so scaling the application out is challenging. Most of the UI functionality is async and queued in memory, and can be silently lost relatively easily. Of course, I can see that running Gitlab probably requires fewer man-hours than developing a new product and then running that. But, it sounds like Fedora would need a lot of customization that upstream would not accept for integration, and the project would be on the hook for maintaining a fork in perpetuity anyway. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Tue, Jul 23, 2019 at 07:18:56AM -0400, Neal Gompa wrote: > On Tue, Jul 23, 2019 at 5:47 AM Kevin Kofler wrote: > > > > Alexander Bokovoy wrote: > > > As I said already, my primary worry is where we would clash our needs > > > with those of GitLab commercial entity. For example, Kerberos > > > authentication or SAML SSO for groups, or push rule restrictions are > > > part of commercial offering but not available in the community edition. > > > This makes it harder to integrate with existing workflows and existing > > > dist-git use. > > > > Indeed, GitLab's crippleware approach might become a problem. > > > > With all those high-profile Free Software projects using GitLab, I wonder > > whether a fork is in order. > > > > If a fork is necessary for GitLab to be usable for high-profile FOSS > projects long-term, then GitLab is a bad fit. The "friendly fork" > model won't work, because rebasing and integrating upstream with > downstream concerns will be incredibly difficult. The "hard fork" > model will fail because GitLab's complexity is incredibly high, making > it functionally impossible for a community to maintain the fork over > time. It would be a repeat of the Alioth situation all over again... > > GitLab's CE/EE split model basically makes it impossible for an > amicable model of community contributions to GitLab, because large > FOSS projects require what they consider Enterprise features. They can > and have rejected things based on this in the past, and will continue > to do so based on that criteria. On the other hand, large FOSS projects are using it. Perhaps we should actually talk with the GitLab folks before deciding they will or won't do something. I've heard they're pretty cool folks. > > Also, for $DAYJOB, I run a GitLab server. If you think maintaining a > GitLab server is easy, you have another think coming. GitLab's > development model basically makes it impossible to have any real > degree of stability, since the codebase churns without concern *very > frequently*. Heck, for three months (that is, three GitLab releases!), > they broke merge requests in GitLab last year when they rewrote merge > requests frontend code in Vuejs... It was that experience that pushed > me to look at Pagure for my personal servers and start contributing to > it in the first place... Sure, sure, but Pagure has regressions too, and plenty of things just don't work for years at a time because it has a fraction of the resources. As a Fedora contributor primary attraction to GitLab to me is that other communities are using it and we can work together. As a user, GitLab's user experience is vastly better. I find Pagure's user experience for code review and CI to be incredibly painful to use. - Jeremy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Tue, Jul 23, 2019 at 5:47 AM Kevin Kofler wrote: > > Alexander Bokovoy wrote: > > As I said already, my primary worry is where we would clash our needs > > with those of GitLab commercial entity. For example, Kerberos > > authentication or SAML SSO for groups, or push rule restrictions are > > part of commercial offering but not available in the community edition. > > This makes it harder to integrate with existing workflows and existing > > dist-git use. > > Indeed, GitLab's crippleware approach might become a problem. > > With all those high-profile Free Software projects using GitLab, I wonder > whether a fork is in order. > If a fork is necessary for GitLab to be usable for high-profile FOSS projects long-term, then GitLab is a bad fit. The "friendly fork" model won't work, because rebasing and integrating upstream with downstream concerns will be incredibly difficult. The "hard fork" model will fail because GitLab's complexity is incredibly high, making it functionally impossible for a community to maintain the fork over time. It would be a repeat of the Alioth situation all over again... GitLab's CE/EE split model basically makes it impossible for an amicable model of community contributions to GitLab, because large FOSS projects require what they consider Enterprise features. They can and have rejected things based on this in the past, and will continue to do so based on that criteria. Also, for $DAYJOB, I run a GitLab server. If you think maintaining a GitLab server is easy, you have another think coming. GitLab's development model basically makes it impossible to have any real degree of stability, since the codebase churns without concern *very frequently*. Heck, for three months (that is, three GitLab releases!), they broke merge requests in GitLab last year when they rewrote merge requests frontend code in Vuejs... It was that experience that pushed me to look at Pagure for my personal servers and start contributing to it in the first place... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
Le 2019-07-23 09:23, Mikolaj Izdebski a écrit : On Mon, Jul 22, 2019 at 11:20 AM Nicolas Mailhot via devel wrote: Huge Red Hat investments, in the Java ecosystem, that fail to translate into an healthy Fedora Java ecosystem. To the point that when IBM wants its Java guys to join there is absolutely no one Fedora-side to provide an on-boarding path. There are multiple active Fedora Java package maintainers employed by Red Hat. I'm among them as full-time packager for RHEL and Fedora, always ready to help newcomers. We have extensive documentation covering specifics of Java packaging. There is no problem with onboarding new Java packagers, other than lack of people to be onboarded. That is not true. Search the list archive for Michael Zhang’s questions on how to get Open Liberty in Fedora. About 4 months later, can anyone do a dnf install open liberty, pointing to a Fedora repo? Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
Le 2019-07-23 08:32, Alexander Bokovoy a écrit : 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. It is unrealistic to expect those repositories to evolve towards something easier to deploy in production, when the tooling we use to prepare and deploy in production is seen as dated, awkward to use, and not keeping up with the times. The first answer language package upstreams will give (and have already been giving for several years) is “fix your own tools and then we'll talk. I don’t want to work with your legacy pile of *.” 20 years ago rpm was on the bleeding edge of innovation and projects were happy to accommodate its needs to partake in a bright new future. It’s not anymore. It didn’t keep up. And that’s not because the people who work on rpm are not outstanding contributors, that’s because they’ve been tasked to do minimal changes without rocking the boat (and given the corresponding resources). Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
Alexander Bokovoy wrote: > As I said already, my primary worry is where we would clash our needs > with those of GitLab commercial entity. For example, Kerberos > authentication or SAML SSO for groups, or push rule restrictions are > part of commercial offering but not available in the community edition. > This makes it harder to integrate with existing workflows and existing > dist-git use. Indeed, GitLab's crippleware approach might become a problem. With all those high-profile Free Software projects using GitLab, I wonder whether a fork is in order. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
Our dist-git stack has a bunch of customization and personalization that are not currently available on gitlab nor any other opensource forge, and some of them will collide with gitlab's CE vs EE edition model, so they'll be hard to get to upstream. Right now we have at least a custom auth provider, unusual ACLs for the standard user, system-wide powerusers, group syncing to the instance, branch ACLs, mass-branching and many more features already implemented that are not going to be easy (or they'll be impossible) to merge on upstream's CE edition. They're working and they're critical on our use case. Almost all the auth privder and ACL things are EE features on gitlab, CE just support basic authentication from providers, no more, and we need a bunch of weird rules there, and we already have them implemented! So, we would have to develop & carry all those things on custom patches, without being able to push them to upstream, so there will not be nor outside contributing to them nor support nor anyone outside fedora will take advantage of our work either, so implementing, maintaing and rebasing all this customization will burden the team again. So, where is the point here? On the other hand, pagure needs a lot of improvement, specially on interface. Internals are decent and they work, we have more problems on UI/API exposition etc. From 400 issues that are right now open on pagure, 200 are RFEs, and the vast majority of them are about UI/API enchancement and similar features. Can we work on this from the community? Would be possible to continue using pagure for dist-git if we go polishing all this things? We don't need a gitlab clone, let the developers host their developing on the forge they want, github, gitlab, event subversion or darcs, it does not matter, our focus should not be cloning gitlab but making a better packaging experience for the packager community, mainly a decent frontend for our packager workflows and there pagure vs cgit is a great improvement. And where is pagure.io with this? Well, if we continue using pagure for dist-git, the development costs of pagure.io should be minimal or zero, since we would be developing it for src.fp.o and other dist-git instances as well, and then we should just have the maintenance costs. Are the pagure.io maintenance costs a big burden for CPE? Let share them with the community. -- Julen Landa Alustiza ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On ti, 23 heinä 2019, Michal Konecny wrote: On 7/22/19 9:04 PM, Jeremy Cline wrote: 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. I totally agree, working on something that will help whole open source community will be much better and much more effective than working on project that is used by Fedora itself. It will also bring more support from open source community itself, because more people using it means more developers that want to work on it. As I said already, my primary worry is where we would clash our needs with those of GitLab commercial entity. For example, Kerberos authentication or SAML SSO for groups, or push rule restrictions are part of commercial offering but not available in the community edition. This makes it harder to integrate with existing workflows and existing dist-git use. GitLab sees those features as enterprise ones and wants to sell them. What does Fedora want to see? -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Mon, Jul 22, 2019 at 11:20 AM Nicolas Mailhot via devel wrote: > Huge Red Hat investments, in the Java ecosystem, that fail to translate > into an healthy Fedora Java ecosystem. To the point that when IBM wants > its Java guys to join there is absolutely no one Fedora-side to provide > an on-boarding path. There are multiple active Fedora Java package maintainers employed by Red Hat. I'm among them as full-time packager for RHEL and Fedora, always ready to help newcomers. We have extensive documentation covering specifics of Java packaging. There is no problem with onboarding new Java packagers, other than lack of people to be onboarded. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
Le 2019-07-22 21:04, Jeremy Cline a écrit : On Mon, Jul 22, 2019 at 06:59:04PM +0300, Alexander Bokovoy wrote: On ma, 22 heinä 2019, Jeremy Cline wrote: 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. It is true of most languages. That’s one core reason Fedora is failing to integrate new big apps (the must-have apps like Apache or Bind were at the turn of the century). Dev tooling has improved a lot in the last 20 years. rpm was “done” and received minimal maintenance. As a result devs are shoveling bad code faster than entities like Fedora manage to integrate it. No packager can handle the amount of upstream churn, when upstream is armed with all kinds of automation and refactoring helpers, while packagers are expected to hand-craft everything like 20 years ago. rpm urgently needs a major rework to work efficiently with 2019 source code (integrate properly with git sources, auto-generate as much as possible, help packagers identify critical cycle break points that need fix up upstream). Or be replaced by something else that does all this. Not another workaround/papering over/templating addon to limit the pain. Not a module system designed to contain the extent of rpm inadequacies. Not a rewrite of spec files in yaml without any other improvement. A real update of our kernel of packaging tools. The core rpm design has aged well. But, it’s being constrained by old bugs, that were acceptable when the amount of packaging was way smaller. And it’s not being applied to 2019 problems. In fact the rpm core design must be terrific, for rpm to keep somewhat relevant in 2019, when it still has not acknowledged the web exists (it‘s been work-arounded with the awful # hack in urls). So it all comes back to the level of investment question. Do rh want to invest in the RHEL/Fedora core, like its future depended on them, and keep it relevant or interesting. Or does it intend to let it slip into comfortable legacy land like the proprietary unixes it replaced, and contributors interested in longer term effects than the next 5 years of RHEL should just look for another hosting organization? Is Fedora’s future just some form of glorified firmware, with no higher-level app included? Without a major rework it will slowly become limited to the packaging of software that was written at the same time, with the same convention, and Fedora as a packaging org will become a legacy pile. rpm, dnf, koji, pagure… they’re all components of the general packaging experience stack. Dropping some of them means the project as a whole does not believe in its own future. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On 7/22/19 9:04 PM, Jeremy Cline wrote: 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. I totally agree, working on something that will help whole open source community will be much better and much more effective than working on project that is used by Fedora itself. It will also bring more support from open source community itself, because more people using it means more developers that want to work on it. Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
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
Re: Discussion around app retirements and categorizations by the CPE team
Jeremy Cline wrote: > 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. KDE is also moving from Phabricator to GitLab. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
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
Re: Discussion around app retirements and categorizations by the CPE team
Le 2019-07-22 17:29, Pierre-Yves Chibon a écrit : On Mon, Jul 22, 2019 at 11:19:17AM +0200, Nicolas Mailhot via devel wrote: Le 2019-07-22 10:22, Miro Hrončok a écrit : > Personally, I wish we had spent less engineering time in > infrastructure on Modularity and more on the contributor UX :( It’s not just Modularity. Modularity is just a symptom. There is something deeply broken in the Red Hat / Fedora interface. RHEL made Red Hat fortunes. It’s what justified the billions IBM paid for it (RHEL is the only Red Hat product where Red Hat completely dominates the market, even the best other offerings, like OpenShift, are just one among many). And Fedora is RHEL’s future. And yet what do we see ? A team that is over-committed and try to scale down to narrow its focus and be in a position to help more the project? And to reinforce, I am speaking about *a team*, not in anyway the whole of Red Hat. Yes, sure, and it’s way better to scale down in a planned way than explode in flight like happened Java SIG. But, in the end, it’s the same root cause: inadequate level of resources just to keep going, because the problem space became more rich and complex, but the level of investment didn’t follow. And I realize it’s a lot easier to write for someone not working @rh, and I’m probably making a lot of persons on the list uncomfortable, but how many Fedora activities need to scale down or close before someone tells the @rh higher ups there is a problem? [...] Huge Red Hat investments, in the container ecosystem. And yet we get told CPE is downsizing its activities, in part because all the new cool things happen in the container space, contributors want to work on cool things, Fedora/RHEL is absent from this space, packaging the things containerized infra need is an afterthought. Could you expend what you mean here? I really do not follow how you go from that first sentence to the second. That was given as one of the reasons in the thread: CPE is downsizing, in part because there are less outsiders willing to work, because the cool stuff is container-side, and CPE does not do it. So we’ve slowly gotten to the point, where non-Fedora @rh initiatives, are vacuuming the cool factor space, that Fedora needs to survive and grow. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Mon, 2019-07-22 at 07:23 -0700, Kevin Fenzi wrote: > > if the Wiki > > explodes and nobody will ever fix it, > > The wiki is fully supported, at least as long as QA uses it for their > TCMS. :) ...and that's likely to remain the case until someone manages to find or write a better one :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On ma, 22 heinä 2019, Jeremy Cline wrote: On Sun, Jul 21, 2019 at 05:37:10PM -0400, Neal Gompa wrote: On Wed, Jul 17, 2019 at 4:31 PM Jeremy Cline wrote: > > On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote: > > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon 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: > > > > > > > > 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. > > I guess my question to all this is... Why? What's the goal? If Keycloak > does everything Ipsilon does and more, what's the point of keeping a > dead project alive instead of contributing to the active, lively one? > > If there really, truly is interest from the broader community, why not > do a friendly fork, get all the work you want in, and see what the > original maintainer thinks? > 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. 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. 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
Re: Discussion around app retirements and categorizations by the CPE team
On Mon, Jul 22, 2019 at 11:19:17AM +0200, Nicolas Mailhot via devel wrote: > Le 2019-07-22 10:22, Miro Hrončok a écrit : > > > Personally, I wish we had spent less engineering time in > > infrastructure on Modularity and more on the contributor UX :( > > It’s not just Modularity. Modularity is just a symptom. There is something > deeply broken in the Red Hat / Fedora interface. > > RHEL made Red Hat fortunes. It’s what justified the billions IBM paid for it > (RHEL is the only Red Hat product where Red Hat completely dominates the > market, even the best other offerings, like OpenShift, are just one among > many). > > And Fedora is RHEL’s future. > > And yet what do we see ? A team that is over-committed and try to scale down to narrow its focus and be in a position to help more the project? And to reinforce, I am speaking about *a team*, not in anyway the whole of Red Hat. [...] > Huge Red Hat investments, in the container ecosystem. And yet we get told > CPE is downsizing its activities, in part because all the new cool things > happen in the container space, contributors want to work on cool things, > Fedora/RHEL is absent from this space, packaging the things containerized > infra need is an afterthought. Could you expend what you mean here? I really do not follow how you go from that first sentence to the second. To me the relation is as obvious as "The sky is blue. And yet we are told that ants can carry 10 to 50 times their body weight", I really do not see the relation nor causality your use of "And yet" seems to imply :) Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Mon, Jul 22, 2019 at 4:59 PM Kevin Fenzi wrote: > > On 7/22/19 1:22 AM, Miro Hrončok wrote: > > On 16. 07. 19 20:18, Pierre-Yves Chibon 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/ > >> > > > > What happens to Pagure? Specifically the dist-git over Pagure part? > > > > If it stays, the front page of a package st src.fp.o might get more love > > and replace apps.fp.o, the Issues tab could be a page that replaaces > > bugz.fp.o, etc. > > > > That said, I'm afraid Pagure might get replaced as well, correct? > > Anything is possible. Personally, I think the customization we have with > pagure over dist git makes it a better frontend for our packages that > any other solutions out there, but I am just one voice. ;) I agree. pagure has matured quite a bit in the last year or so. For example, the Stewardship SIG uses pagure (and pagure-over-dist-git) for 90% of all out activities, including PRs, PR reviews, ticketing system, ... and it works really well for that. I'd have no idea what to replace it with should either of the pagure instances ever be shut down (or replaced with something inferior again). Fabio > > Anyway, I respect your decisions and I understand that maintaining > > everything was not sustainable. However I guess that if we replace > > Pagure with e.g. GitLab and all our customization is gone, > > Yeah, that would be a fair pile of work to get things into a shape we > can find usable I think. It's definitely not something that will happen > overnight. > > if the Wiki > > explodes and nobody will ever fix it, > > The wiki is fully supported, at least as long as QA uses it for their > TCMS. :) > > > if mailman3 goes away and is > > replaced by some contracted solution, > > ...which could be mailman3, just run by people who do that full time... > > > and when Badges die, it will be a > > Hopefully we can get enough interest to move badges to a more community > supported application. > > > sad day for the Fedora contributor community, possibly making > > contributing to Fedora even harder than it become over the past few years. > > > > Personally, I wish we had spent less engineering time in infrastructure > > on Modularity and more on the contributor UX :( > > > > I hope this transition will go as smoothly as possible. Good luck guys! > > > > (And please keep in mind that even if I criticize some things a lot, I > > still consider you Fedora superheros.) > > Thanks. None of this is easy for us, I assure you. > > kevin > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On 7/22/19 1:22 AM, Miro Hrončok wrote: > On 16. 07. 19 20:18, Pierre-Yves Chibon 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/ >> > > What happens to Pagure? Specifically the dist-git over Pagure part? > > If it stays, the front page of a package st src.fp.o might get more love > and replace apps.fp.o, the Issues tab could be a page that replaaces > bugz.fp.o, etc. > > That said, I'm afraid Pagure might get replaced as well, correct? Anything is possible. Personally, I think the customization we have with pagure over dist git makes it a better frontend for our packages that any other solutions out there, but I am just one voice. ;) > Anyway, I respect your decisions and I understand that maintaining > everything was not sustainable. However I guess that if we replace > Pagure with e.g. GitLab and all our customization is gone, Yeah, that would be a fair pile of work to get things into a shape we can find usable I think. It's definitely not something that will happen overnight. if the Wiki > explodes and nobody will ever fix it, The wiki is fully supported, at least as long as QA uses it for their TCMS. :) if mailman3 goes away and is > replaced by some contracted solution, ...which could be mailman3, just run by people who do that full time... > and when Badges die, it will be a Hopefully we can get enough interest to move badges to a more community supported application. > sad day for the Fedora contributor community, possibly making > contributing to Fedora even harder than it become over the past few years. > > Personally, I wish we had spent less engineering time in infrastructure > on Modularity and more on the contributor UX :( > > I hope this transition will go as smoothly as possible. Good luck guys! > > (And please keep in mind that even if I criticize some things a lot, I > still consider you Fedora superheros.) Thanks. None of this is easy for us, I assure you. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Sun, Jul 21, 2019 at 05:37:10PM -0400, Neal Gompa wrote: > On Wed, Jul 17, 2019 at 4:31 PM Jeremy Cline wrote: > > > > On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote: > > > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > > > 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: > > > > > > > > > > > > > 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. > > > > I guess my question to all this is... Why? What's the goal? If Keycloak > > does everything Ipsilon does and more, what's the point of keeping a > > dead project alive instead of contributing to the active, lively one? > > > > If there really, truly is interest from the broader community, why not > > do a friendly fork, get all the work you want in, and see what the > > original maintainer thinks? > > > > 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. > > 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. > > 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
Re: Discussion around app retirements and categorizations by the CPE team
Le 2019-07-22 10:22, Miro Hrončok a écrit : Personally, I wish we had spent less engineering time in infrastructure on Modularity and more on the contributor UX :( It’s not just Modularity. Modularity is just a symptom. There is something deeply broken in the Red Hat / Fedora interface. RHEL made Red Hat fortunes. It’s what justified the billions IBM paid for it (RHEL is the only Red Hat product where Red Hat completely dominates the market, even the best other offerings, like OpenShift, are just one among many). And Fedora is RHEL’s future. And yet what do we see ? Highly-visible Red Hat investments on the desktop, where the focus is on creating flatpacks to deprecate Fedora as soon as possible. If you read the marketing messages you’d think Silverblue was the only Fedora today and rpm packaging a thing of the past. Even though Silverblue is incomplete by design, since it does not want to address anything except desktop deployments. Huge Red Hat investments, in the Java ecosystem, that fail to translate into an healthy Fedora Java ecosystem. To the point that when IBM wants its Java guys to join there is absolutely no one Fedora-side to provide an on-boarding path. Huge Red Hat investments, in the container ecosystem. And yet we get told CPE is downsizing its activities, in part because all the new cool things happen in the container space, contributors want to work on cool things, Fedora/RHEL is absent from this space, packaging the things containerized infra need is an afterthought. As a result of short-term delivery focus, with no work on long term packaging and maintenance, we're seeing the same explosion of bundling and forking and API incompatibilities container-side we saw Java-side before, with the same highly predictible long term outcome. Red Hat is taking RHEL and Fedora for granted. There is no business drive to keep Fedora strong and growing, and lots of internal incentives to work instead on the next best purported value-added thing. There is no business drive to keep code healthy and maintenable long term, and lots of incentives to invent band-aids like modularity, to contain the rot some more till it’s someone else’s problem. There is no business drive, to create solutions, that can be deployed and used by joe nobody packager. And without those, there is no potential of long-term packaging community and no Fedora (let's cut the fluff Fedora is a lot of things but at core it’s a packaging community). Well all that happened to others before, and one day the golden goose will be gone. And why am writing about this non-Fedora sponsor things? Because Fedora has stewardship instances, that are supposed to tell those things to the generous sponsor, and keep it informed of the real state of its sponsored project. And, they are clearly failing to pass the message. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On 16. 07. 19 20:18, Pierre-Yves Chibon 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/ What happens to Pagure? Specifically the dist-git over Pagure part? If it stays, the front page of a package st src.fp.o might get more love and replace apps.fp.o, the Issues tab could be a page that replaaces bugz.fp.o, etc. That said, I'm afraid Pagure might get replaced as well, correct? --- Anyway, I respect your decisions and I understand that maintaining everything was not sustainable. However I guess that if we replace Pagure with e.g. GitLab and all our customization is gone, if the Wiki explodes and nobody will ever fix it, if mailman3 goes away and is replaced by some contracted solution, and when Badges die, it will be a sad day for the Fedora contributor community, possibly making contributing to Fedora even harder than it become over the past few years. Personally, I wish we had spent less engineering time in infrastructure on Modularity and more on the contributor UX :( I hope this transition will go as smoothly as possible. Good luck guys! (And please keep in mind that even if I criticize some things a lot, I still consider you Fedora superheros.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Sun, Jul 21, 2019, 22:38 Neal Gompa wrote: > On Wed, Jul 17, 2019 at 4:31 PM Jeremy Cline wrote: > > > > On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote: > > > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon < > pin...@pingoured.fr> 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: > > > > > > > > > > > > > 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. > > > > I guess my question to all this is... Why? What's the goal? If Keycloak > > does everything Ipsilon does and more, what's the point of keeping a > > dead project alive instead of contributing to the active, lively one? > > > > If there really, truly is interest from the broader community, why not > > do a friendly fork, get all the work you want in, and see what the > > original maintainer thinks? > > > > 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. > > 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. > > 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 4:31 PM Jeremy Cline wrote: > > On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote: > > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > > 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: > > > > > > > > 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. > > I guess my question to all this is... Why? What's the goal? If Keycloak > does everything Ipsilon does and more, what's the point of keeping a > dead project alive instead of contributing to the active, lively one? > > If there really, truly is interest from the broader community, why not > do a friendly fork, get all the work you want in, and see what the > original maintainer thinks? > 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. 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. 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
Re: Discussion around app retirements and categorizations by the CPE team
On 7/17/19 10:00 PM, Emmanuel Seyman wrote: My initial reaction is that the lists of applications in categories 1 and 2 are very short. My second reaction is that this page doesn't sell me that I should use Python in any business-critical software... These categories are not complete at all. We didn't go through every application we own and put it to specific category. We only got through part of our list. It will be long process till we get through whole list. In the first CPE blog [0] about changes in our team you can see that we are currently maintaining 112 services and we have only 19 people to do this. Is release-monitoring.org also maintained by the CPE? It's being broken for ages and I feel it's a shame it doesn't get more love. I'm the main maintainer/developer of release-monitoring.org and I recently deployed a new version to staging environment, but I'm currently busy working with others on Rawhide Gating. I will have talk about future of release-monitoring.org on Flock, you can meet me there and we could discuss about this or feel free to add any bug to release-monitoring.org tracker [1]. There is currently one issue, that is blocking reporting bugs in bugzilla, unfortunately this is issue on bugzilla [2] side. I'm also trying to write blog posts [3] regularly about my work. Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Michal [0] - https://communityblog.fedoraproject.org/state-of-the-community-platform-engineering-team/ [1] - https://github.com/release-monitoring/anitya/issues [2] - https://bugzilla.redhat.com/show_bug.cgi?id=1679385 [3] - https://communityblog.fedoraproject.org/tag/release-monitoring-org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On 7/17/19 10:40 AM, Timothée Floure wrote: > Hello, > > I do not think it would be good for apps.fp.o to simply disappear: although > outdated, it does a pretty good job improving human-discoverability of our > services. I understand that longtime or active contributors are not really > affected but I believe the index to be helpful for newcomers (as it was in my > case). > > From apps.fp.o's README [1]: >> Right now, the apps side of Fedora Infrastructure feels scattered and all >> over the place. It seems like I learn that a new thing exists every couple >> weeks and it seems like there's not a single easy place where you can stumble >> into everything. > > Can we perhaps move the index to the main docs on [2] and replace the current > apps.fp.o by a simpler, intemporal page, linking to the updated list? Having > the page out of the 'standard' documentation workflow doesn't help keeping it > up-to-date... > > I will gladly take care of the changes. Any thoughts? I personally think thats a fine idea... might be good in a infrastructure specific area? We also have 'infra-docs' that might be good to move into the main docs site sometime ( https://docs.pagure.org/infra-docs/ ) Thanks! kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 2019-07-17 at 22:00 +0200, Emmanuel Seyman wrote: > My initial reaction is that the lists of applications in categories 1 and 2 > are very short. Category 1 is not a list. It says: "For completeness we are highlighting one example of a Category 1 application that we will always aim to maintain and keep on the air." - i.e. there are several *other* things in Category 1. It's not entirely clear from the post whether the 2, 3 and 4 lists are meant to be complete, but from knowledge and belief I think at least 2) is not: there are other things than the wiki that would fall into that category. (I sure hope openQA does, cos we can't easily run it in Openshift, for instance). > My second reaction is that this page doesn't sell me that > I should use Python in any business-critical software... I'm not quite seeing the logic there? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
* Peter Robinson [17/07/2019 14:07] : > > It would be useful to have the CPE mission linked to directly, it's > mentioned a number of times in the post but I don't see a direct way > to get to it. It's in the first link on that page: https://communityblog.fedoraproject.org/outcome-of-the-cpes-teams-face-to-face/ Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
My initial reaction is that the lists of applications in categories 1 and 2 are very short. My second reaction is that this page doesn't sell me that I should use Python in any business-critical software... Is release-monitoring.org also maintained by the CPE? It's being broken for ages and I feel it's a shame it doesn't get more love. Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote: > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > 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: > > > 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. I guess my question to all this is... Why? What's the goal? If Keycloak does everything Ipsilon does and more, what's the point of keeping a dead project alive instead of contributing to the active, lively one? If there really, truly is interest from the broader community, why not do a friendly fork, get all the work you want in, and see what the original maintainer thinks? 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. - Jeremy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 15:38, Adam Williamson wrote: > On Wed, 2019-07-17 at 13:32 -0400, Neal Gompa wrote: > > My frustration is that people who aren’t working at Red Hat have *no* > > avenue to help support the Project’s infrastructure. > > On what basis do you say this? The whole infra process is set up to be > a Fedora process, not an RH one. You don't use any RH credentials to do > any work on Fedora infra. You use Fedora ssh tokens and certificates. > The servers are Fedora servers, hosted in a Fedora data centre. There's > You were doing so well up until this point. The majority of the servers are owned by Red Hat and the majority of them are hosted in 2 data centres that are rented by Red Hat. Stephen 'equally picky when its over 38 C' Smoogen -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On 7/17/19 10:32 AM, Neal Gompa wrote: > > I don’t have a problem with you saying you can’t maintain everything > and focusing on stuff *to* maintain. But I have been trying for > *months* to try to help in various efforts as a member of the > community. There’s very little I can do because there’s just simply no > avenue for the community to be involved. I'm pretty shocked that you say that, but obviously there's some miscommunication going on, we should try and figure out how to fix it. > I took over maintenance of the pagure package in Fedora and EPEL > because pingou couldn’t keep up with it and everything else for this > reason. In the process of that, I’ve become a contributor and try to > help where I can. Thats great, thanks! > And I’ve had a standing offer open with abompard to co-maintain the > Mailman 3 stack as soon as it landed in Fedora. It’s still valid, even > today. Yep. He has had no time to polish things up, get them working with python3.7 and submit them. If you're willing you could ask him for the python 3.4 based packages to try and bring up and get reviewed. I can't speak for him of course. > I’m happy to do the same for Ipsilon, and I’d even like to become a > contributor once I’ve had a chance to get up to speed with it, like I > did for Pagure. Great! > My frustration is that people who aren’t working at Red Hat have *no* > avenue to help support the Project’s infrastructure. Granted, this > isn’t exclusively a Fedora thing. CentOS has this problem, and > openSUSE is worse, since all of their maintenance scripts are > completely private behind a VPN that only SUSE employees have access > to. Thats... not the case. Or shouldn't be. I was in sysadmin-main (root on all hosts) before I worked for Red Hat. For years. Others also joined via the community and were later hired by Red Hat. ...snip... I think there's several possible disconnects/issues around this. Fedora Infrastructure has always been very 'self driven' for contributions. We have had to be, due to the amount of time folks have to help / mentor people. So we see this a lot: Them: Hey! I want to help out with infrastructure! us: awesome! we have added you to the apprentice group to login and look around, please join our meetings, read our getting started guide, hang out in our channels and ask questions or chime in when you see something you want to help with, and look at our tickets. Welcome. Them: The folks who have done well with this model just start working on things, sending patches, asking on irc if they can help with X specifically, etc. Thats not great for people who want to be assign tasks or have a mentor. Additionally, the model has been that new folks start out with things, do them well then do more things and as they go they get perms to do those things. Many people want to jump to the end. "I want to maintain koji, give me access". Finally, infrastructure isn't nearly as interesting as it used to be. Many of the folks that would have been interested in helping are now off looking at openshift and openstack and microservices and other more exciting things. Anyhow, if there are specific things you want to commit to helping with or doing, let us know and we can try and get you able to do those things. It's not a cabal. We would love to have the help. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 14:10, Neal Gompa wrote: > On Wed, Jul 17, 2019 at 1:22 PM Stephen John Smoogen > wrote: > > > > > > > > On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: > >> > >> On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > wrote: > >> > > >> > >> 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… > >> > >> > > > > I don't know what is worse.. that if we try to improve things by saying > we can't maintain everything we are crap, or if we don't try to improve > things by maintaining stuff poorly we are crap. Do you want to beat us in > the morning or evening or just both times so you can work out your > frustrations on how badly we do stuff? > > > > Again my comments were not helpful and not useful for this conversation. > > My frustration is that people who aren’t working at Red Hat have *no* > avenue to help support the Project’s infrastructure. Granted, this > isn’t exclusively a Fedora thing. CentOS has this problem, and > openSUSE is worse, since all of their maintenance scripts are > completely private behind a VPN that only SUSE employees have access > to. > > I will be the first to admit that the various programs Infrastructure has run to try and get community members have not worked well. The problem being that the apprentice program and others need a lot more day to day hands on training we don't have time to do while trying to keep the ship from burning to the waterline. That means that while we try to get people involved, it turns into a large amount of we aren't available when the apprentice/newperson is and they aren't when we are. That said, we are putting everyone including new Red Hat people through being an apprentice before they get to join a sysadmin group. Then they are added to various sysadmin-* groups that fit the work they are doing. > But what is the point of saying stuff like this when we don’t have a > way to be a part of it? You’ve basically handed down ultimatums to the > entirety of the Fedora Project, contingent on the mostly RHer Fedora > Council (who has access to information the rest of us can’t ever get, > since we’re not employed by Red Hat) approving it. > > What information do you want? We have put out a list of all the applications we have, we are trying to make sure that we make people put in a ticket for things versus pinging us personally so it can be measured, and we have tried to make our infrastructure open for people to see what is done in it. That said there is always more things which can be done. > > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 2019-07-17 at 13:32 -0400, Neal Gompa wrote: > My frustration is that people who aren’t working at Red Hat have *no* > avenue to help support the Project’s infrastructure. On what basis do you say this? The whole infra process is set up to be a Fedora process, not an RH one. You don't use any RH credentials to do any work on Fedora infra. You use Fedora ssh tokens and certificates. The servers are Fedora servers, hosted in a Fedora data centre. There's a whole system by which you can apply to be an infrastructure team member which is not tied to RH employment. Did you try going through this process? Did it not work? https://fedoraproject.org/wiki/Infrastructure/GettingStarted -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 20:10, Neal Gompa wrote: > > On Wed, Jul 17, 2019 at 1:22 PM Stephen John Smoogen wrote: > > > > > > > > On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: > >> > >> On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > >> wrote: > >> > > >> > >> 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… > >> > >> > > > > I don't know what is worse.. that if we try to improve things by saying we > > can't maintain everything we are crap, or if we don't try to improve things > > by maintaining stuff poorly we are crap. Do you want to beat us in the > > morning or evening or just both times so you can work out your frustrations > > on how badly we do stuff? > > > > I don’t have a problem with you saying you can’t maintain everything > and focusing on stuff *to* maintain. But I have been trying for > *months* to try to help in various efforts as a member of the > community. There’s very little I can do because there’s just simply no > avenue for the community to be involved. > > I took over maintenance of the pagure package in Fedora and EPEL > because pingou couldn’t keep up with it and everything else for this > reason. In the process of that, I’ve become a contributor and try to > help where I can. > > And I’ve had a standing offer open with abompard to co-maintain the > Mailman 3 stack as soon as it landed in Fedora. It’s still valid, even > today. > > I’m happy to do the same for Ipsilon, and I’d even like to become a > contributor once I’ve had a chance to get up to speed with it, like I > did for Pagure. > > My frustration is that people who aren’t working at Red Hat have *no* > avenue to help support the Project’s infrastructure. Granted, this > isn’t exclusively a Fedora thing. CentOS has this problem, and > openSUSE is worse, since all of their maintenance scripts are > completely private behind a VPN that only SUSE employees have access > to. > > But what is the point of saying stuff like this when we don’t have a > way to be a part of it? You’ve basically handed down ultimatums to the > entirety of the Fedora Project, contingent on the mostly RHer Fedora > Council (who has access to information the rest of us can’t ever get, > since we’re not employed by Red Hat) approving it. > > I fully expect that the Council will approve this, because they’ve > been saying for months that Fedora Infra’s team can’t support it all. > But that’s the problem. It’s *not* a Fedora team. It’s *just* Red > Hatters who happen to work on Fedora. And their priorities are handled > based on all the things they work on, and that includes CentOS and > maybe even other things as part of Red Hat’s OSPO (though I’m not sure > of that just yet…). > > I’m not trying to beat you guys up, but I don’t know what you want > from us. Based on my personal experience, it’s hard for me to be > enthusiastic about helping anymore… I think what you describe Neal is the effect of the team being overloaded, there is simply not enough hours in the week (and some of us are working a crazy number of hours per week) for us to keep everything running and also be able to help with more community involvement at least this is my feeling. A lot of the discussion we had was based on the value the CPE team brings to Fedora. The reality is that we have limited resources and way *too* many projects
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 13:46, Brian (bex) Exelbierd wrote: > On Wed, Jul 17, 2019 at 6:44 PM Stephen John Smoogen > wrote: > > > > > > > > On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: > >> > >> On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > wrote: > >> > > >> > >> 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… > >> > >> > > > > I don't know what is worse.. that if we try to improve things by saying > we can't maintain everything we are crap, or if we don't try to improve > things by maintaining stuff poorly we are crap. Do you want to beat us in > the morning or evening or just both times so you can work out your > frustrations on how badly we do stuff? > > Stephen, I respect your read and interpretation of what is written by > Neal above. I also understand your lived experience. > > Thank you for your line, but you don't have to respect my comments as mine showed little respect to Neal or the list. I should not have sent it as is, I should not have flown off the handle, and I apologize for the comments. > I think what Neal is getting at is that we don't have any knowledge > yet about how the services we are looking for others (not infra team > members) to run will be managed. The current system is less than > desirable and what Neal is referencing. It'd be great to get more > detail about how we are enabling these apps to be run by others so we > can see what is possible. > > regards, > > bex > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
Hello, I do not think it would be good for apps.fp.o to simply disappear: although outdated, it does a pretty good job improving human-discoverability of our services. I understand that longtime or active contributors are not really affected but I believe the index to be helpful for newcomers (as it was in my case). From apps.fp.o's README [1]: > Right now, the apps side of Fedora Infrastructure feels scattered and all > over the place. It seems like I learn that a new thing exists every couple > weeks and it seems like there's not a single easy place where you can stumble > into everything. Can we perhaps move the index to the main docs on [2] and replace the current apps.fp.o by a simpler, intemporal page, linking to the updated list? Having the page out of the 'standard' documentation workflow doesn't help keeping it up-to-date... I will gladly take care of the changes. Any thoughts? [1] https://github.com/fedora-infra/apps.fp.o [2] https://docs.fedoraproject.org/en-US/docs/ Cheers, -- Timothée signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
> "FW" == Florian Weimer writes: FW> I strongly doubt this will be true indefinitely. I expect things FW> will change pretty quickly once partners can access and file bugs in FW> the other bug tracker. This is interesting in light of the fact that one reason given for not enabling Pagure issues for src.fedoraproject.org was because there was benefit in keeping bugs in bugzilla alongside the RHEL bugs. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 1:22 PM Stephen John Smoogen wrote: > > > > On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: >> >> On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon >> wrote: >> > >> >> 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… >> >> > > I don't know what is worse.. that if we try to improve things by saying we > can't maintain everything we are crap, or if we don't try to improve things > by maintaining stuff poorly we are crap. Do you want to beat us in the > morning or evening or just both times so you can work out your frustrations > on how badly we do stuff? > I don’t have a problem with you saying you can’t maintain everything and focusing on stuff *to* maintain. But I have been trying for *months* to try to help in various efforts as a member of the community. There’s very little I can do because there’s just simply no avenue for the community to be involved. I took over maintenance of the pagure package in Fedora and EPEL because pingou couldn’t keep up with it and everything else for this reason. In the process of that, I’ve become a contributor and try to help where I can. And I’ve had a standing offer open with abompard to co-maintain the Mailman 3 stack as soon as it landed in Fedora. It’s still valid, even today. I’m happy to do the same for Ipsilon, and I’d even like to become a contributor once I’ve had a chance to get up to speed with it, like I did for Pagure. My frustration is that people who aren’t working at Red Hat have *no* avenue to help support the Project’s infrastructure. Granted, this isn’t exclusively a Fedora thing. CentOS has this problem, and openSUSE is worse, since all of their maintenance scripts are completely private behind a VPN that only SUSE employees have access to. But what is the point of saying stuff like this when we don’t have a way to be a part of it? You’ve basically handed down ultimatums to the entirety of the Fedora Project, contingent on the mostly RHer Fedora Council (who has access to information the rest of us can’t ever get, since we’re not employed by Red Hat) approving it. I fully expect that the Council will approve this, because they’ve been saying for months that Fedora Infra’s team can’t support it all. But that’s the problem. It’s *not* a Fedora team. It’s *just* Red Hatters who happen to work on Fedora. And their priorities are handled based on all the things they work on, and that includes CentOS and maybe even other things as part of Red Hat’s OSPO (though I’m not sure of that just yet…). I’m not trying to beat you guys up, but I don’t know what you want from us. Based on my personal experience, it’s hard for me to be enthusiastic about helping anymore… -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 6:44 PM Stephen John Smoogen wrote: > > > > On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: >> >> On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon >> wrote: >> > >> >> 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… >> >> > > I don't know what is worse.. that if we try to improve things by saying we > can't maintain everything we are crap, or if we don't try to improve things > by maintaining stuff poorly we are crap. Do you want to beat us in the > morning or evening or just both times so you can work out your frustrations > on how badly we do stuff? Stephen, I respect your read and interpretation of what is written by Neal above. I also understand your lived experience. I think what Neal is getting at is that we don't have any knowledge yet about how the services we are looking for others (not infra team members) to run will be managed. The current system is less than desirable and what Neal is referencing. It'd be great to get more detail about how we are enabling these apps to be run by others so we can see what is possible. regards, bex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > wrote: > > > > 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… > > > I don't know what is worse.. that if we try to improve things by saying we can't maintain everything we are crap, or if we don't try to improve things by maintaining stuff poorly we are crap. Do you want to beat us in the morning or evening or just both times so you can work out your frustrations on how badly we do stuff? -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 4:13 PM Neal Gompa wrote: > > On Wed, Jul 17, 2019 at 10:09 AM Florian Weimer wrote: > > > > * Peter Robinson: > > > > >> > 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. > > >> > > >> Sunsetting Mailman sounds pretty harsh. Will Red Hat do the > > >> contracting, or is it up to every sub/side-project to host their mailing > > >> lists? > > >> > > >> Bugzilla isn't mentioned. Has it been evaluated in this context? > > > > > > I believe bugzilla is maintained by an internal team and as such is > > > outside of the CPE team's scope and hence unaffected. > > > > I strongly doubt this will be true indefinitely. I expect things will > > change pretty quickly once partners can access and file bugs in the > > other bug tracker. > > > > I’m assuming you are referring to Red Hat’s JIRA instance? > > (For shame that they’re using JIRA, but there’s nothing we can do about it…) I encourage us to focus on the rescoping work the infrastructure team is doing and identifying challenges/issues/means of support for that. A discussion of bug trackers is definitely nothing but rehashing old news. RH may or may not be changing the way it tracks bugs, but so far they haven't tried to deprecate any pathways Fedora uses. Matthew, Ben and I keep an eye on these things assisted by a literal metric ton of RHers who value and are passionate about Fedora. Bugzilla is currently maintained for us. If that changes we can react, but lets focus on what we know is changing now. regards, bex > > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexel...@redhat.com | b...@pobox.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 10:09, Florian Weimer wrote: > * Peter Robinson: > > >> > 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. > >> > >> Sunsetting Mailman sounds pretty harsh. Will Red Hat do the > >> contracting, or is it up to every sub/side-project to host their mailing > >> lists? > >> > >> Bugzilla isn't mentioned. Has it been evaluated in this context? > > > > I believe bugzilla is maintained by an internal team and as such is > > outside of the CPE team's scope and hence unaffected. > > I strongly doubt this will be true indefinitely. I expect things will > change pretty quickly once partners can access and file bugs in the > other bug tracker. > > I think the word unaffected means something different in what Peter was trying to communicate. It is 'unaffected' by our plans in the same way that we can't easily affect the weather in Brazil. Thus it is not in the scope of things we can say we are ending, adding, changing, moving to a PDP-11 cluster in Devonshire, etc. > Thanks, > Florian > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 10:09 AM Florian Weimer wrote: > > * Peter Robinson: > > >> > 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. > >> > >> Sunsetting Mailman sounds pretty harsh. Will Red Hat do the > >> contracting, or is it up to every sub/side-project to host their mailing > >> lists? > >> > >> Bugzilla isn't mentioned. Has it been evaluated in this context? > > > > I believe bugzilla is maintained by an internal team and as such is > > outside of the CPE team's scope and hence unaffected. > > I strongly doubt this will be true indefinitely. I expect things will > change pretty quickly once partners can access and file bugs in the > other bug tracker. > I’m assuming you are referring to Red Hat’s JIRA instance? (For shame that they’re using JIRA, but there’s nothing we can do about it…) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 03:20:34PM +0200, Florian Weimer wrote: > * Peter Robinson: > > >> > 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. > >> > >> Sunsetting Mailman sounds pretty harsh. Will Red Hat do the > >> contracting, or is it up to every sub/side-project to host their mailing > >> lists? > >> > >> Bugzilla isn't mentioned. Has it been evaluated in this context? > > > > I believe bugzilla is maintained by an internal team and as such is > > outside of the CPE team's scope and hence unaffected. > > I strongly doubt this will be true indefinitely. I expect things will > change pretty quickly once partners can access and file bugs in the > other bug tracker. You can have your doubts but what Peter said is true. CPE is not responsible for maintaining bugzilla, so it's very much out of our scope :) Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
* Peter Robinson: >> > 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. >> >> Sunsetting Mailman sounds pretty harsh. Will Red Hat do the >> contracting, or is it up to every sub/side-project to host their mailing >> lists? >> >> Bugzilla isn't mentioned. Has it been evaluated in this context? > > I believe bugzilla is maintained by an internal team and as such is > outside of the CPE team's scope and hence unaffected. I strongly doubt this will be true indefinitely. I expect things will change pretty quickly once partners can access and file bugs in the other bug tracker. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 11:46 AM Pierre-Yves Chibon 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/ It would be useful to have the CPE mission linked to directly, it's mentioned a number of times in the post but I don't see a direct way to get to it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
> > 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. > > Sunsetting Mailman sounds pretty harsh. Will Red Hat do the > contracting, or is it up to every sub/side-project to host their mailing > lists? > > Bugzilla isn't mentioned. Has it been evaluated in this context? I believe bugzilla is maintained by an internal team and as such is outside of the CPE team's scope and hence unaffected. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
* Pierre-Yves Chibon: > 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. Sunsetting Mailman sounds pretty harsh. Will Red Hat do the contracting, or is it up to every sub/side-project to host their mailing lists? Bugzilla isn't mentioned. Has it been evaluated in this context? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
