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. 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. 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. I have not yet seen a practical example of merged source trees improving the quality of package maintenance. [1]: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects -- 真実はいつも一つ！/ 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
