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 > gitlab.com, 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 the changes: * 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 > src-git. 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 infrastructure > 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 (https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx/message/IZR5U35NLGUDRI2BOZDNKGUMHVAJF3UH/) and it's never been successful. That's basically _why_ pagure came along. 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 this backlog: * https://pagure.io/pagure/issues 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. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
