On Tue, Nov 20, 2018 at 01:36:06PM -0500, Neal Gompa wrote: > 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: > > > > > > 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. That's an argument for merged source trees, as it makes maint easier allowing maintainers to get more work done in less time. > 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. Well we just fundamentally disagree - heavy patch loads are not an inherantly bad thing that needs discouraging. They're only bad if they are full of non-upstreamed stuff. If they're pulling bug fixes into Fedora to improve our quality they are a very good thing. > > 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. libvirt / qemu really don't have a stupid high patch load in Fedora because Fedora's 6 month cycle means they're never very far behind upstream. Most of the patches to QEMU tend to be CVE backports. Rebasing to new versions inside the stable releases is not a straightforward thing. There is always a risk of regression when doing that and users get very upset of a previously working guest OS stops booting due to rebasing in middle of a stable release. We have rebased in the past but not any more because not rebasing leads to a more stable offering on balance. > > > 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? Upstream QEMU releases once every 4 months and libvirt monthly. Even if we did change our minds & decide to rebase, it is still too long to wait for pulling in security fixes and other critical functional fixes. > 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. I will always prefer to rebase to newer versions if I think it is viable without too high a risk of regressions. Even if rebasing frequently there's still a need to maintain patches and anything that makes that easier is a win. Use of merged source trees for maint doesn't have any bearing on the willingness to take rebases or leave patches downstream-only. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
