On Tue, Nov 20, 2018 at 12:49 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: > > > > > > On Tue, Nov 20, 2018 at 1:57 PM Michal Novotny <clime@xxxxxxxxxx> wrote: > > >> > > >> On Tue, Nov 20, 2018 at 12:43 PM Tomas Tomecek <ttomecek@xxxxxxxxxx> wrote: > > >>> > > >>> > * Matthew Miller: > > >>> > > > >>> > > > >>> > Make it cheap to maintain branches. I expect that one what to achieve > > >>> > this would be to build directly out of Git, with synthesized release > > >>> > numbers and changelogs. This way, you can apply a lot of fixes to > > >>> > 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 https://pagure.io/rpkg-util/blob/master/f/macros 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: https://github.com/user-cont/source-git/blob/3f0875dcaa08a48562d19879cf53104bcac5cdd4/README.md > > > > > > > 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[1]. > > > > 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 much, either. All of those things are around the "negative" or "pessimistic" viewpoint. 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 > upstream. > 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 you > > 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! _______________________________________________ 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
