LWN: Comments on "An uproar over the Fedora Git forge decision"

An uproar over the Fedora Git forge decision

donbarry — Fri, 24 Apr 2020 01:34:38 +0000

Thanks for this old and precious memory, it feels like yesterday that I read this, and it's shocking that it's now 16 years.

That was the straw that pushed me from Redhat to Debian, and I've never looked back.

An uproar over the Fedora Git forge decision

abo — Sun, 19 Apr 2020 08:12:55 +0000

From the CPE Weekly:
"We are opting for Gitlab for our dist git and project hosting"

It doesn't really make sense to treat "Gitlab" as a single option. The different editions should be evaluated separately and eliminated individually based on requirements.

By treating them as a single option Pagure would first be compared to the non-free Gitlab on functional requirements, and then the Gitlab editions would only be compared against each other when it came to possible F/OSS and self-hosting requirements.

"dist-git" vs "git-forge"

mathstuf — Fri, 17 Apr 2020 17:37:58 +0000

Sure. I'll try and write up an email by tomorrow.

"dist-git" vs "git-forge"

Conan_Kudo — Fri, 17 Apr 2020 12:36:12 +0000

This stuff looks interesting for both pagure.io and src.fedoraproject.org... Would you consider introducing this to the community? There's a mailing list (pagure-devel@lists.pagure.io) and an IRC channel (#pagure on Freenode).

An uproar over the Fedora Git forge decision

re:fi.64 — Fri, 17 Apr 2020 02:17:29 +0000

Absolutely brilliantly stated, I almost wish there were a way to "like" comments on LWN now.

"dist-git" vs "git-forge"

mathstuf — Thu, 16 Apr 2020 20:20:48 +0000

Shameless plug here.

At work, we went to GitLab (CE) years ago. To make up for some gaps in functionality to match our workflow, we had our own robot which was on Gerrit first adapted into a Python script. Later features ended up making that gotta-get-it-working attempt a dead end and now it's a set of Rust crates. Granted, it's more tuned for actual projects rather than the kinds of repos `.spec` files tend to live in, but it has these things which may be useful:

- code checks (also possible via CI usually)
- reformatting (if rpmlint --fix exists) branches (instead of "You're not formatted right. Here's a diff, go apply it then come back to me.")
- performing merges (with backporting available, though Fedora usually does fast-forward, that'd be possible here too)
- because it performs the merge, you can keep the actual merge button away from everyone and instead just let the robot have elevated privileges (I have a task to make it check for approvals and block merging without, but it's just been a wishlist item so far)

The infrastructure is such that it could be used for Pagure as well (it currently just supports GitHub and GitLab) if it has a suitable API to fill out the information needed by the various actions.

Repo with the actions: https://gitlab.kitware.com/utils/rust-ghostflow
Available content checks (extensible by other crates if needed): https://gitlab.kitware.com/utils/rust-git-checks
The webhook-based daemon: https://gitlab.kitware.com/utils/ghostflow-director

I'd like to get it to work as a CI job rather than via webhooks, but there are various blockers to that (time for GitHub and various feature requests are in on GitLab). Fedora might prefer webhooks though (for centralization of the configuration).

An uproar over the Fedora Git forge decision

NYKevin — Thu, 16 Apr 2020 18:36:10 +0000

Feel free, I stole the core ideas from someone else.

An uproar over the Fedora Git forge decision

amacater — Thu, 16 Apr 2020 18:08:52 +0000

Can I steal this, please, and walk it into a large organisation to show them? :) This is a great summary of a whole bunch of things and is cogent and easy to understand - even for middle managers.

An uproar over the Fedora Git forge decision

NYKevin — Thu, 16 Apr 2020 17:59:48 +0000

There is a tendency in these discussions to anthropomorphize large corporations. Which is dangerous, because it is grossly inaccurate to reality.

A large corporation is difficult to steer from the top (because of the sheer number of decisions to be made overall) and impossible to steer from the bottom (because the most you can do is convince one manager at a time to support your way of thinking). The people who are really steering are hundreds or thousands of middle managers, each of whom has a slightly different understanding of the business's high-level needs and goals, a moderately different set of internal resources and levers of power, and a radically different understanding of the business's immediate problems. Every now and then, their collective decision-making is bad enough that an executive gets involved and tells them "you screwed up, now fix it." Every now and then, their collective decision-making is good enough that the corporation does something that looks very smart, to an outside observer. But most of the time, the corporation drunkenly shambles in the general direction of profitability, while the outside world tries to figure out what on Earth it could possibly be thinking. This is the wrong question. Corporations don't think. The people running the corporation think, but there are many of them and each one has a peculiar and limited understanding of the corporation's broader scope.

(Some large corporations are better at dealing with this problem than others, in some cases a lot better. But they all suffer from it to some extent.)

TL;DR: Never ascribe to malice that which can be adequately explained by collective decision-making, because the latter is amazingly inefficient.

An uproar over the Fedora Git forge decision

djc — Thu, 16 Apr 2020 15:20:59 +0000

"We last looked in ... at the end of January" -- except there was a short-form LWN item that saw quite a bit of discussion:

https://lwn.net/Articles/816282/

An uproar over the Fedora Git forge decision

madhatter — Thu, 16 Apr 2020 05:50:35 +0000

Wow, does this ever remind me of something: https://lwn.net/Articles/83360/

Plus ca change, plus c'est la meme chose.

"dist-git" vs "git-forge"

pizza — Thu, 16 Apr 2020 00:43:41 +0000

Using GitLab as a "git-forge" (aka random project hosting) is relatively uncontroversial, though it was pointed out that several of Pagure's supposed deficiencies (notably https access to repositories) were actually intentional, to meet operational requirements imposed by Red Hat.

Meanwhile, what really has everyone up in arms here is that Fedora has a great deal of custom tooling that makes up "dist-git" -- aka the core infrastructure that used to put together the distribution. Currently this is all very tightly tied into Pagure, and would have to be largely recreated for GitLab -- as would many other GitLab features that don't exist in the open-source "community edition".

No effort was made to quantify the scope, effort, or cost of reworking dist-git to work on top of Gitlab, nor the effort needed to bring Gitlab CE to the level of necessary functionality to ingegrate into other Fedora infrastructure. Would Gitlab accept features into CE that they have intentionally left out (to make the proprietary versions more attractive?) Has CPE taken into account the ongoing cost of maintaining their own fork of Gitlab CE?

And what would be the outcome if all of that reinventing-the-wheel effort were to be put into improving Pagure instead?

An uproar over the Fedora Git forge decision

Conan_Kudo — Thu, 16 Apr 2020 00:29:57 +0000

It's important to note that the Pagure community didn't even know the decision until after it was announced. At no point was there an opportunity for the project contributors to analyze and prioritize what CPE wanted from a Git forge.

Generally speaking, throughout the process, the Fedora community has largely said that their needs were met and that they were happy with what Pagure provided as Fedora's Dist-Git server.

Is it perfect? No. But in general, as user requests were coming in from Fedora, they were being prioritized and worked on, even though CPE was not working on Pagure in that timeframe. In the past 18 months, Pagure made a major version release, and then made a dozen successive feature and bugfix releases on almost a monthly cadence. The project is still getting features, contributors, and interest from other parties.

By all rights, Pagure is probably the most successful project from the Fedora Engineering team (which was absorbed into the CPE team). Unlike HyperKitty and Ansible, which neither are associated with Fedora even though both were created in Fedora, Pagure is very much associated with the Fedora Project, and has provided an opportunity to show that Fedora is a place where innovation can happen.

As a member of the Pagure community myself, I intend to continue to support the project the best that I can, and help drive interest, adoption, and increase contributors. I love Pagure not just because it's a cool project that I can grok and contribute to, but because it's a project that makes Free Software and open data principles the forefront of software project development and management. And that those features can potentially be used for supporting federated/decentralized development is an awesome cherry on top! And all that is important to me. Joey Hess said that open data for Git hosting is the single most important part of replacing Github, and this is something Pagure does right, as all project data is stored as Git repos you can mirror, interact with, or whatever. I hope others will see the potential in Pagure, use it, and also contribute to its future development.