Randy, thank you for providing such detailed information! A few comments inline.
On Wed, Jun 30, 2021 at 3:01 AM Randy Barlow via devel < devel@lists.fedoraproject.org> wrote: > 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: > After reading your explanation of how gentoo does packaging, it indeed makes a lot of sense and feels like that most of the concerns I pointed out have solutions or could be mitigated. The biggest problem I personally see is the effort which would be needed to pull this off: it would take years to accomplish, a ton of teams would be involved and all the maintainers would need to cooperate - and then we'd need to do the same thing for CentOS Stream and RHEL. Such a change to the development workflow would be massive and the level of coordination would be immense. That's all I can say. * 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. > Since we all would work in a single git repo, I'm assuming the pulls would be cheap most of the time. CI and builders would probably need a caching mechanism so the repo wouldn't need to be fetched from scratch all the time. > * 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. > Well, tests could be stored alongside packaging files as they are right now. > * 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 ☺ > Looks like the gentoo-bot is a critical piece of the development process so that people are able to progress with their contributions efficiently. 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 ☺) > Monorepo source-git wouldn't work, our SSDs are not that big, yet :D Thanks Randy for such a great write-up. Now that I think about it, the monorepo proposal is orthogonal to the source-git proposal as the two workflows serve different purposes: one is meant for development (source-git: write a patch), the other one for integration into the operating system (tinker with a spec file or the build system). Tomas
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
