On Thu, Dec 6, 2018 at 7:59 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * 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. > Sure, fork traps and such do still happen, but they're a lot rarer because that is much more painful with our current packaging model. It's a lot more obvious that package is in bad shape when it has ~100+ patches and is hard to rebase than it is when you have Git trees and can just do merges all the time. Once you've done merges, it becomes impossible to sort out. > > 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? > I think that if you're maintaining large patch sets that you might want to consider talking to upstream about doing more releases. If glibc has so many problems that this becomes an issue even with the short life cycle in Fedora, then maybe upstream needs to reconsider its release model a bit and do more frequent releases per version series. Actually, does it even do that now? I'm not actually sure... > 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. > My understanding is that we allowed the feature in because it was actively being shepherded into glibc upstream. However, shortly after it was included in Fedora, the change owners stopped working on it upstream (from what I can tell). As a consequence, the C.UTF-8 locale is probably what I would consider one of our biggest failures. It's present in Fedora, openSUSE, Debian, and now Mageia. But it isn't present upstream. No one is working on it upstream, and I have very little hope for the developers of that locale to finish the job they started. We do not usually screw up that badly in the distribution in such a way that we have such a deviation from upstream and simultaneously stop working on upstreaming the change or consider to drop it because it isn't being upstreamed. > > 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. > It's a lot clearer that patch files applied to a tarball are distinctly packager things vs a cacophony of changes from upstream and downstream mixed together. Aside from the rdopkg triple-repo process that Ken brought up in the thread, I don't know of any clean process for making these changes identifiable. > 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. > That is not the same thing. This is about sorting out who did what and why, not what happened. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
