On Tue, May 5, 2020 at 7:25 PM Neal Gompa ngompa13@gmail.com 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