* 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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
