On Mon, Nov 29, 2021 at 12:06:13PM -0600, Michael Catanzaro wrote:
Hi, I have a question for the FESCo and Council candidates: do you
support allowing Fedora src-git repositories to be hosted on
, which a proprietary software git forge?
I am not one of these candidates, but I think the answer here _has_ to be
"yes", and not just for GitLab but also GitHub. That's because unlike
dist-git (which is all in one place, _here_), source-git is intended to be
distributed and close to upstreams. It should be possible to create a
source-git repo in the git forge the upstream project prefers.
From the design document (https://packit.dev/docs/source-git/design/
Content of source-git repository is equivalent to dist-git, but uses
upstream format: source files instead of tarballs, git commits
instead of patches.
You can host this repository, or the specific git branch, anywhere
you want. If you open a pull request, you will receive feedback on
* Does the package build with the changes?
* Do all the package tests pass?
* How about tests of the dependant packages?
* Are the changes good to be included in Fedora?
The goal of packit is to provide automation and tooling to interact
with source-git repositories so you don’t have to touch dist-git ever
again. Our plan is to center development experience around upstream
repositories and source-git.
Upstream repositories and source-git repositories are pretty much
the same thing. Creating source-git only makes sense when the upstream
does not accept downstream spec file or adding spec file to such a
project doesn’t make sense.
Forbidding source git repositories in the most popular git forges in the
world would be kneecapping ourselves and not, actually, moving us
closer towards our project vision.
Fedora Council has already effectively stated that dist-git
infrastructure must remain open source, but has no such promises for
I would like to very carefully say that the Fedora Council is not in
the business of making permanent promises. We ALWAYS have to be able to
adapt as circumstances change. The only promise I'll make is that we
will always have a community-based decision making process. But that
doesn't mean we won't need, as a community, to sometimes re-evaluate
our positions, even when that's hard.
I understand Council has previously stated that Fedora
should depend on proprietary software only if no open source
alternative is suitable. Do you believe that there exist no open
source git forges that would be suitable for Fedora src-git?
See above; that's not really the right question. Restricting source-git
to any particular git forge is not suitable.
The most obvious open source alternative would be the open source
version of GitLab. There is also Pagure. I think we're giving up on
open source infrastructure rather quickly here. I'd like to know
what the candidates think before voting.
Rather quickly seems... rather dismissive. Leaving aside the
particulars of source-git.... people have been saying "let's set up
Gitlab in Fedora" for at least ten years
and it's never been successful. That's basically _why_ pagure came
It's pretty easy to armchair dictate that the project use some piece of
software. But for source git — and dist-git — we need long-term comment
to run it. We don't have that for an open source gitlab project, and,
frankly, we don't have it for Pagure. Pingou is awesome and is doing
heroic work _literally_ above and beyond the call of duty, and there is
some help from others (hi Neal, Michal Konečný, others), but... look at
and perhaps more harshly, look at the closed issues and merged PRs and
how long it's been since something significant happened. This project
is in emergency maintenance-only state.
Would I like there to be a kick-ass option crushing proprietary and
open core git forges? Yes, yes I would. (In fact, I think Gitlab _could
be that_ if they would take the leap, and I'm absolutely going to keep
pushing them for that.) But we don't have one now.
Could we set up open-source Gitlab and run that? Well, history has
shown that the answer is "probably not, actually". And it's _really
hard_ for me to go to Red Hat and say "hey, um, I know you're paying
for this Gitlab contract we can use, but can you please do this huge
project, with ongoing maintaince forever, to set up and run the
all-open-source version in addition to that?"
I mean, it's not hard for me to _say_ that. But it's going to hard to
get an answer that's anything but, "I get where you're coming from, but
we don't have extra resources for that." And it _is_ hard for me to say
"okay, well, use a significant portion of the resources you're
dedicating to Fedora to do that" — there's such a long, big backlog of
important things that _aren't_ running our own gitforge.
And that goes for not-Red Hat, too, really. If that's is what's
_really_ important to you (the general you, not just you, Michael) and
you want to do it and can provide the level of support and commitment
Fedora needs to keep being successful and _making our distro_, okay,
that's fine.... people choose what to work on, after all. But there are
so many other projects that seem more interesting....
Let's do Flatpaks better. Like, source-git _right to flatpak_, but with
the same advantages get and provide to our users. Let's do sandboxing
like you (Michael, this time) have been saying we need for users. Fix
deltarpms — or make Silverblue so _really really awesome_ that they're
irrelevant for most users. Deploy a new open metrics-collection system
so translators know what to focus on. Make the Fedora KDE Plasma Spin
the best KDE version of any distro. Make the gaming experience on
Fedora Workstation _or_ KDE completely seamless. Make the Fedora Cloud
Edition so compelling that Amazon decides they'll just use it directly.
Make Fedora IoT the defacto distro for robotics. Make the compose take
less than 30 minutes. Completely automate generating RCs. Make it so
anyone can generate a new Spin and release it independent of the main
schedule. Make CoreOS for RiscV. Automate so much more of the standard
test matrices. Move to a new test-case-management system. And let's
have a Badges system that's responsive and easy to update. A new
website with content easily managed by the various edition and spins
teams. Can we have search on docs? And more docs overall, really. Can
someone help write the docs we're waiting on for our Matrix launch?
Also, make RPM specfiles have zero boilerplate. Automatically re-review
those specfiles on an ongoing basis and convert to newer standards.
Figure out something actually interesting for java and node and all the
other language stacks with their own package management. Update of our
old fedmsg stuff so there's schemas. Hook more stuff to
fedora-messaging. Make charts and graphs for everything! Use ML to help
triage bugzilla. Build everything in the Fedora dist-git for EPEL, and
build some CentOS Stream stuff back for Fedora for people who need
compat packages. Have some kind of not-hand-rolled API to
authoritatively tell the currently supported releases. PDC — don't we
need one of those? And that's all stream of conscious... I'm sure
you've ALL got so much more.
Fedora Project Leader