Re: Is dist-git a good place for work?
On Tue, May 5, 2020 at 7:25 PM Neal Gompa <ngompa13(a)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