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@xxxxxxxxxxxxxxxxxxxxxxx> 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@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
