On Tue, Nov 20, 2018 at 12:49 PM Daniel P. Berrangé <berrange(a)redhat.com> wrote:
On Tue, Nov 20, 2018 at 12:15:17PM -0500, Neal Gompa wrote:
> On Tue, Nov 20, 2018 at 12:03 PM Michal Novotny <clime(a)redhat.com> wrote:
> > On Tue, Nov 20, 2018 at 1:57 PM Michal Novotny <clime(a)redhat.com> wrote:
> >> On Tue, Nov 20, 2018 at 12:43 PM Tomas Tomecek <ttomecek(a)redhat.com>
> >>> > * Matthew Miller:
> >>> >
> >>> >
> >>> > Make it cheap to maintain branches. I expect that one what to
> >>> > this would be to build directly out of Git, with synthesized
> >>> > numbers and changelogs. This way, you can apply a lot of fixes
> >>> > multiple branches without encountering mandatory conflicts.
> >>> We are aiming for something similar what you just described. I created
this wiki page to describe the work briefly:
> >>> https://fedoraproject.org/wiki/CI/source-git
> >>> The actualy work is happening here now:
> >>> https://github.com/user-cont/source-git
> >>> We would love to take development off dist-git (but keep dist-git!) and
move it to git repos with real source code which match upstream repositories. In such repo
you have branches which track respective Fedora versions -- you can easily cherry pick
fixes. We would validate every pull request in such repo and stuff would get merged only
when it passes testing. Right now we are trying to write minimal code to make such thing
work, evaluate it and present at devconf.cz to get some more feedback.
> >>> Hopefully we would utilize clime's work to help with changelogs and
release numbers: https://pagure.io/rpkg-util/pull-request/15
> >> So that would be cool if my work is actually used. I recommend looking at
specifically if you could use that.
> >> I planned to open a PR for python-rpkg do enable this functionality in
Fedora but I am being delayed by work on rpkg-3.0, which is yet another *pkg client.
> >> Anyway, if there is some interest in making this available in Fedora soon,
I can happily do it first. Just kick (contact) me.
> >> To be clear, the macros can only do the second point from "What and
why?" at https://github.com/user-cont/source-git
> > The README was changed meawhile so the second point from here:
> The problem with merged source trees (aka source-git) is that it
> implies forking projects. It's an easy trap to start having vendor
> trees and maintain your own functionality independent from upstream.
> 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.
> 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.
IMHO this is an overly negative view. It is making a presumption
that package maintainers are in general bad at what they do and
must be made to jump through hoops to "force" them to do the
right thing, no matter what the cost to good maintainers.
This is a fairly realistic view, because I assume packagers are
inherently lazy when it comes to maintenance. That is, they'll take
the easiest path possible. And that's perfectly rational.
I think we should design our systems around a positive viewpoint,
where package maintainers are in general good at what they do
and make life as easy as possible for those people.
If we designed our systems around "positive viewpoints", then email
based code contribution would have completely died out. We wouldn't
have aggravating systems like Gerrit. We wouldn't really look at CI
All of those things are around the "negative" or "pessimistic"
With email based contribution, it's designed around forcing people to
sift through mail list archives to figure out what's going on, and
forcing other people to review changes on a patch by patch basis,
rather than as a whole series. Gerrit is a step up from that, but
still imposes pain on both sides specifically because it assumes that
individual patches are bad. These models are all about inflicting pain.
CI systems are designed around the fact that most people do not test
or validate their code changes to make sure they work. Or if they do,
they don't quite hit all the cases. And CI deals with that.
You're confusing this with trust. And yes, there's some trust to give
here, but keeping a (tiny) amount of friction for small patch sets
that increases as your patch load goes up just further encourages not
maintaining heavy patch loads.
No matter what we do there will always be maintainers who don't
do a good job at sending stuff back upstream. We see that today
in places but they are a minority. Most people learn pretty quickly
that updating downstream-only patches to work with new versions
is painfull and so it is in their own interests to get stuff
In the case where patch management is required, rather than git merges
or rebases, people learn this very quickly. They also learn to make
patches more logically self-contained to make it easier for
maintenance. Most people have very different strategies for git
commits vs actual patches.
Even today though, we could & should do more to identify where
we have problems. ie something that looks at patches applied in
Fedora, and reports on how long they have existed for, and across
how many version rebases they've existed. This could show places
where extra help / push is needed to get stuff back upstream.
It actually would be pretty neat if we could have a patch tracker, and
even a way to explore trees run through rpmbuild -bp. That would make
it easier for exploring and debugging the code that makes up Fedora.
> 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.
> I know this because it was a problem where I work before I banished
> merged source trees where I work, and it remains an issue for Linux
> distributions that operate this way too.
You can't actually "banish" merged source trees in practice. At most
you end up pushing them behind the curtain where you won't see them,
but they still very much exist. There are already packages maintained
this way with dist-git merely getting automated imports of patches
from the merged source tree. I maintain my own packages this way
whenever I need to pull bug fixes back to Fedora from upstream.
To be honest, I do this for some packages as well when there are
non-trivial patch sets. But for me, that is used primarily for
identifying patches to submit upstream.
And yes, I do cherry-pick fixes from upstream and backport them, but
for my maintenance, I try very hard to avoid it and instead move
forward to newer versions.
This, of course, is not always possible, but that's the way I approach it.
> When patches are a burden, you will only do it when needed, and
> feel more compelled to try to avoid it. Ironically, that makes it
> easier to move faster and update more frequently.
This is assuming the main use of patches is to add non-upstream
changes to Fedora. The more common use of patches is likely to be
backporting of fixes already existing upstream.
I'd probably say that the majority of patches are fixes to fix package
builds or something of that nature. And a minority of those are never
upstreamed for various reasons.
IOW, when patches are a burden, the maintainers are less likely
to fix bugs present in Fedora, even if the fix is available
upstream. This is counter to what our users want/expect.
You're assuming that packages have stupid high patch loads like
libvirt and qemu do. Most don't. And really, the fact you guys just
backport a bunch instead of just bumping to new versions is something
I've never really understood.
> I have not yet seen a practical example of merged source trees
> improving the quality of package maintenance.
I'll have to disagree on this. I've found merged source trees to make
it significantly quicker and more reliable for me to get fixes from
upstream pulled back into Fedora packages.
Is that because upstream is too slow to release fixes, or is that
because you don't like bumping to new versions?
Merged source trees make it much easier to not update the software.
But split source trees (like our current model) encourage fixes to be
pushed upstream and bend workflows towards updating to newer versions
because that's easier.
真実はいつも一つ！/ Always, there's only one truth!