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. 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. 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. 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. > 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. > 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. 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. > 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. 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
