Re: Fedora Lifecycles: imagine longer-term possibilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux