On Mon, Nov 29, 2021 at 03:25:29PM -0600, Michael Catanzaro wrote: > On Mon, Nov 29 2021 at 03:15:24 PM -0500, Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > source-git is intended to be > > distributed and close to upstreams. > > Interesting. Why? What you and David are both saying seems so weird to me, I > suddenly wonder if I am seriously misunderstanding something, because I know > you're reasonable people and must have thought about this for longer than > me. But it sounds pretty awful? > > src-git is exclusively used for downstream Fedora packaging, so I don't > expect upstreams to be interested at all, unless upstream developers are > also the Fedora packagers, right? I'm also assuming that direct commits to > dist-git will be blocked if src-git is enabled -- because otherwise how > would we keep them in sync and avoid breaking src-git? -- and the only way > to commit to dist-git would be via src-git. Is that right too? > > So we want to move Fedora packaging closer to upstream and away from Fedora? > I just don't get it. Won't that make life harder for Fedora packagers, > especially provenpackagers? If src-git is distributed such that you can have > src-git repositories anywhere, then contributing to arbitrary Fedora > packages becomes pretty annoying, right? E.g. imagine if we moved our > gnome-shell packaging to src-git and decided to use gitlab.gnome.org, > because that is close to upstream. Then suddenly you need an account on > gitlab.gnome.org if you want to contribute to Fedora's gnome-shell package? > Now next time the library xyz package maintainer -- who has nothing to do > with GNOME -- wants to rebuild every Fedora package that depends on library > xyz, it requires opening a merge request on gitlab.gnome.org, because that's > where the Fedora packaging lives? How would that even work for releng > scripts like mass rebuilds? This is only thinking of the negatives though. There are also potentially positives to being closer to the upstream. One of the things I see a struggle with from the upstream POV is the maintaining of stable branches of existing releases. A lot of distros effectively maintain stable branches on behalf of the u pstream, but each in their own little silo. Some are much better than others, so we get a pretty inconsistent pattern across distros. This is not good for users, nor a good use of downstream maintainers time. The downstream maintainers aren't nudged towards sharing the work, because they are all in their own distro specific tooling world. In a source git world we've taken a step towards maintaining downsteam patches in a manner which is a better fit for the way upstreams maintain patches in stable branches. From that starting point it is only a small addition nudge to actually maintain the src-git tree in upstream, or near enough to upstream that it is worth sharing the work with other distro maintainers. Of course there are exceptions to the rule, and some packages have lots of distro specific patches (eg those that have to strip out crypto to apply rules that only impact Fedora). Most packages though have patches that are not distro specific. I'm not saying collaboration will magically happen. Just that a source-git model that is close to, or part of, upstream repos will remove a significant barrier, making cross distro collaboration as a more realistic possibility than it is today. > > Could we set up open-source Gitlab and run that? Well, history has > shown that the answer is "probably not, actually". > > I don't believe it. If GNOME and KDE and freedesktop.org and Debian and > Purism can all do it, I'm pretty sure Fedora can too. GNOME has two > sysadmins handling all of GNOME infrastructure, one of whom is part-time, > but GNOME GitLab never seems to lag too far behind upstream. I think it is clear that it is possible to self-host GitLab. It is more than just sysadmin time involved though. One of the most compelling parts of GitLab is its CI framework and the free runners it provides projects. If you're runing your own GitLab instance you need to bring your own runners, and if it becomes popular this can be incredibly costly in terms of compute time. Even if you don't bring runners, and require people to provide their own, there are still overheads in storage. This caused some problems for Freedesktop.org in the past: https://lists.freedesktop.org/archives/wayland-devel/2020-February/041232.html [quote] The bad news: The cost in growth has also been tremendous, and it's breaking our bank account. With reasonable estimates for continued growth we're expecting hosting expenses totalling 75k USD this year, and 90k USD next year. With the current sponsors we've set up we can't sustain that. We estimate that hosting expenses for gitlab.fd.o without any of the CI features enabled would total 30k USD, which is within X.org's ability to support through various sponsorships, mostly through XDC. [/quote] Fedora sees many (probably all) of these costs already in various other parts of its infra, but it is wise to consider whether this is the best use of our resources, if it is practical to leverage an existing hosted resource. NB, I'm not for or against self-hosting in this respect. Using gitlab.com isn't a clear win on the financial side either for a project as large as Fedora. Any CI runtime allowance for gitlab.com we get probably won't end up being sufficient, requiring us to bring our own runners anyway. My point is simply that the decision on whether to self-host is not as simple & clearcut as it might seem on the surface, even considering that other existing OSS projects doing it. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
