On Tue, 2021-06-29 at 15:36 +0200, Tomas Tomecek wrote: > > On the "uni-repo" counter proposal: there's a bunch of real-world > > examples here of distributions using this successfully: > > https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow Hey Tomas! As Colin noted above, Gentoo uses a single repo (well, technically, they also have overlays, but the main distro is just one git repo is what I mean…) I'll add some comments to your thoughts below: > * Can you imagine maintaining Fedora's 30k+ packages in a single repo? > Without some git-fetch magic it would be unbearable to perform a git-pull. Gentoo has 19,302 packages according to their packages web app[0]. Some Gentoo packages map to more than one Fedora package, since Gentoo has slots and uses USE flags. For example, there's just one package called "python", but you can get various Python versions from the same name (vs how we have a separate package for each Python version in Fedora). Programs with lots of plugins end up being one package that has USE flags for the plugins, where in Fedora the plugins might be packages separately. An example of this is gstreamer - in Gentoo I just have gstreamer installed, and the various plugin packs like good bad and ugly are just USE variables on that one package. I mention these differences to say that it's probably fair enough to compare the set to Fedora's 30k. I will say that a git pull does take some time, especially if you haven't run it very recently. It's not unusable, but you do notice it for sure. I just ran a quick test on two different systems with wildly different results: * On a system with an ssd I hadn't pulled for two days, and a git pull took 0m3.357s. * On a system with a spinny disk I hadn't pulled since January 17, and a git pull took 1m27.878s. I'd say that this is probably close to a "worst case" scenario, except that I do have a 200 Mbps internet connection. Most of the time was spent doing stuff with the disk and not on network. I could imagine a slow network making this even longer. I would say this is the top downside to the monorepo approach that I personally experience. But I also tend to use the SSD system for this, and also tend to pull often enough that it's not a big deal. > * Git history would be immensely bloated (though `git log $path` > would work well). Yeah I always just use git log $path myself, and it works fine. I also think it's kinda cool that I can tail a single git log and see what people have been up to across the project, but we can also do that with the message broker in Fedora. > * On the other hand, I like that changes could be done "atomically" > in a single commit, even for multiple packages. I *love* this, and to me it's the best thing about the design. If you have a change to one package that requires a corresponding change in others, you just do it in a single commit. In Fedora we don't have an easy automatic process for this. We *could* build one, but it would be harder to do. With a monorepo, it's just something you get for free. > * How would CI function? Due to the atomic commit, I'd say CI could function better because you know what changes need to be tested together. Gentoo doesn't have per-package CI that I'm aware of, but they do have general checks that they do on all packages. They've got a QA bot that check PRs on GitHub and marks them as pass/fail. > * Where and how would tests be stored? As said, I don't think Gentoo does this, but I could imagine having a tests/ subfolder in the package's folder, not too different from what we do now. > * As Neal pointed out, ACL mechanics would need to be thought > through. GitHub does have a codeowners feature, which I think could be adapted for this purpose. One could imagine a server-side git push hook that checks an ACL rule list against the paths that were altered. I think such a thing could probably be implemented in not GitHub as well. I wouldn't say it's trivial to do so, but not extremely difficult either. > * src.fp.o and koji would need to be updated, significantly. Agreed. > * How would contributions be handled? It would be hard to detect > stalled PRs, maintainers would be swarmed with changes not related to > their packages. Here's an example of a Gentoo PR I worked on recently: https://github.com/gentoo/gentoo/pull/20975 Note that there are two bots that have commented on it. The interesting one for this question is gentoo-bot - it came and marked the PR with some metadata, helpful links into the bug tracker, CoC, and other stuff, and most usefully, labeled the PR with some special labels. If Fedora had such a bot you could imagine it doing things like assigning it to the right person (or otherwise notifying them), pinging long-open PRs, or other things like that. The other bot on that PR is the Gentoo QA bot, and it does some basic checks on your commit to make sure you followed some basic rules/guidelines. It's not the same thing as what we have in Fedora. We do have PRs in Fedora that stay open for a long time too, so I don't think that's a monorepo vs. lots-of-repos problem ☺ Oh, and one other thought, Gentoo is not doing what we call source-git either. Like us, the packages operate on a tarball, typically from upstream, and then they apply patches to them as needed. I think it would be probably too extreme to do a source-git thing with a monorepo (like, if the kernel source code and the Firefox source code and the GNOME source code were all in the same repo, that would probably be a bit much ☺) [0] https://packages.gentoo.org/
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
