On Tue, May 5, 2020 at 7:25 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > Hello Tomas, > > I have a fair bit of experience with operating in both so-called > "source-git" and "dist-git" workflows. I've known them by the names of > "merged-source" and "split-source" trees respectively, so forgive me > if I use that terminology, since it makes conveying the point a bit > easier. Thank you for the description and context. I'm actually not a fan of the term "source-git" honestly - I'd love to call it "upstream git" since that's what we are trying to do - use the repository layout which is well-known in the upstream community. > Obviously, you understand the advantages of this approach (managing > patches is easier as Git commits, you have access to rebase and merge > logic for code, etc.). However, in my experience seeing these in use > at a large scale, the major downside is that it inhibits the need to > work with the software developers of the project to contribute > improvements. Sometimes this is unavoidable (the RHEL ipa, kernel, > rpm, samba, and systemd packages come to mind here), but most of the > time, I don't see these large fork trees being necessary in RHEL or > Fedora. In general, where I've seen this implemented on a distro-wide > scale, the contribution levels from the distribution drop by a large > margin. There is also the added issue of it becoming a lot more > difficult to sort through the differences between upstream and > downstream changes. They all look the same in the merged-source model, > which makes it hard for others to discover Fedora-only changes and > potentially help to bring those changes upstream. I'd say this is a good point and I still recall as we discussed this in person on Summit last year. What I really love about Fedora (and Red Hat) is the upstream first principle - when a downstream bug (or just a problem) appears, the maintainers are focused on bringing the solution upstream as the first thing to do. I can still see how people do this and I'm just so proud. Neal, you're right that with the source-git model, maintainers may be tempted not to bring the changes upstream - I'd say that should be a point where we should introduce changes to the system to motivate people to follow upstream first and help them achieve it. > There is also that any source-git/merged-source model would require > forking into Fedora's server (src.fedoraproject.org) in a new > namespace (sources) and have the same restrictions that the > split-source/dist-git model has (no rebasing, no branch deletion, no > tag updating, etc.). Not doing so would cause major problems in terms > of reproducible builds, but this also makes working with the source > tree a lot more painful. Perhaps if we never directly built from it > and exported released sources as tarballs, then it wouldn't be > necessary, but those are details to figure out if we move forward with > this idea. +1 Neal, thank you for the great feedback and thorough insights, 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
