On Tue, Jun 29, 2021 at 12:48 AM Colin Walters <walters@xxxxxxxxxx> wrote: > > > > On Thu, Jun 24, 2021, at 5:16 AM, Tomas Tomecek wrote: > > Greetings from the Fedora source-git SIG! We are planning to start > > publishing reports of what we are working on so everyone can easily > > pay attention and get involved if interested. If you have any ideas, > > comments or requests, don’t be shy and let us know :) > > I really appreciate your efforts here. I think most of us know > that the current RPM workflow is very antiquated. > > However, two things: > > - The representation for how we maintain source code is a > very long-term commitment. It's hard to maintain multiple > of them. Related to that, the details of how this works > will quickly become "frozen" and hard to change, so > it's important to get it right from the start. Related > to that: Yes, we can see that happening right now: doing some fundamental changes to the current development process takes months/years/Ø. > - I think this proposal only benefits very few packages, > mainly kernel/grub where the upstream is large > and we carry nontrivial deltas. For most others, > it will either be neutral or worse. So...my counter > proposal is to iterate closer to a NixOS/OpenEmbedded style "uni-repo" > model, leaving these special cases to basically become > forked upstream repositories. Instead of carrying 208+ > patches to grub, we'd have a separate git repo that gets rebased. > Which...is how it already works at https://github.com/rhboot/grub2/tree/fedora-35 > it looks like. > > 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 This is a nice write-up and the idea is definitely appealing but I can't personally imagine how would this scale in Fedora: * 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. * Git history would be immensely bloated (though `git log $path` would work well). * On the other hand, I like that changes could be done "atomically" in a single commit, even for multiple packages. * How would CI function? * Where and how would tests be stored? * As Neal pointed out, ACL mechanics would need to be thought through. * src.fp.o and koji would need to be updated, significantly. * How would contributions be handled? It would be hard to detect stalled PRs, maintainers would be swarmed with changes not related to their packages. Would be awesome to get a PoC of this uni-repo approach. 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
