* Neal Gompa:
The problem with merged source trees (aka source-git) is that it
implies forking projects.
But that's true for *any* distribution that wants to integrate things.
I guess you could govern everything by build flags eventually, but
upstreams will rarely be willing to backport those to older branches
(if they even have release branches as such).
It's an easy trap to start having vendor trees and maintain your
own
functionality independent from upstream.
And how does the current dist-git prevent that? I know packages which
have managed to fall into the fork trap even with dist-git.
Fundamentally, I don't want having patches to be too easy,
because
then people _will_ do that. Fedora should strive to remain close to
upstream projects and interact with them to make things better[1].
To be honest, that's an awful attitude.
Do you want me to spend time on packaging work instead of glibc
maintenance? Do you really think that's a good use of my time?
Do you really think an unavoidable conflict each time you merge parallel
development into a source RPM provides value?
And the thing is, it's not like I'm unfamiliar with merged
source
models. I've worked in distributions that operated that way, and the
consequence is almost always that things are patched and changed
without ever interacting with upstream. Of course, that's their choice
to do so, but most distributions do not have "upstream-first" as a
specific goal.
We do that in Fedora, too.
A recent example is the switch to the C.UTF-8 locale, which is not
upstream *at all*. It was pointed out at the time, and the issue was
completely ignored.
In addition, it may seem like it makes things easier (and maybe
faster), but it actually makes things much harder and slower for
everyone else. Merged source trees make it so that it's stupid easy to
have light forks of everything, which means people will just patch and
change things without consequence. That makes it much harder to
identify changes for rebasing to newer versions, what's safe to drop,
and so on.
That's just a matter of tooling. A lot of information can be recovered
from Git history, and it's going to be easier to do this in a single
repository than with copied patches, without tooling that enforces that
the patches actually contain what they say.
The point is to keep that history around. With the current model, the
information might theoretically be available somewhere, but with the
split between Fedora, branches, wildly differing patch management
practices, in addition to all the upstream differences we encounter,
it's extremely difficult to recover.
In a sense, it's the old discussion between explicit rename recording
and rename detection. I think it's clear by now that rename detection
has won.
Thanks,
Florian