On Tue, 5 May 2020 at 13:06, Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 05. 05. 20 12:41, Tomas Tomecek wrote: > > Before I reply, I'd like to stress that we are still in a prototype > > phase - not everything is solved (clearly) and at this point, we > > experiment with the workflow mostly. > > Experimenting is cool. Go ahead. As long as this is totally opt-in and does not > affect me as a contributor even if the main package maintainer chooses to use > it, all is good. > > > Luckily, force-pushes are not allowed in dist-git, which makes the > > update/sync process easier (knowing that history cannot be changed). > > Therefore when a new commit lands in dist-git, we'd just "transform" > > it to source-git and pushed it to the source-git repo. We could even > > ask all the contributors to rebase their PRs when this happens. > > On the other hand, when a new commit lands in the source-git repo, we > > could either transform and push to dist-git directly or open a PR. The > > maintainer should be in control of this process. > > That sounds overly complicated. I thought the idea is to make thing easier, what > am I missing? > > > I understand the synchronisation adds friction to the overall > > architecture and may be the cause of many problems in the future - > > hence we are starting this discussion and using the technology > > ourselves to catch these issues asap. > > Good! > > > Miro, you are talking about conflicts: I'd say that conflicts on the > > git level are normal and git has solid tools to resolve them. For the > > use case of 2 different people changes the same thing, we would treat > > dist-git as the authoritative place and let the person in source-git > > know about the conflict. But this can happen nowadays easily as well: > > 2 different people can open the same PR or even push to dist-git > > directly while only one would succeed. > > No, actually, that is a misunderstanding. I was simply talking about > synchronization. But you have basically already answered my question above: When > changes are done in dist-git, they will be somehow replicated in the source-git > thing. > > > Petr, I should have probably stressed that our target is Fedora (or > > even all Red Hat operating systems). Yes, there are hundreds of > > distributions and we cannot solve their problems. We are open for > > collaboration though - we cannot drive changes in distributions which > > we don't know or use. > > Do I understand correctly that you no longer aim for the "put Fedora spec files > upstream" thing, but rather, "create an intermediate upstream sources / fedora > scpec file" git repo hybrid? What's the benefit? > > ---- > > See for example with Python. We have some patches (although we are trying to get > rid of them) and rebasing those has proven to be quite tedious with patch files > only. > > Hence, we keep this fork: https://github.com/fedora-python/cpython Imho, it would be nice if this could live on src.fp.o in a separate dedicated namespace for source repos. > > It has our patches on top. When new version is released, we rebase our branch > with git. We format-patch the commits and put them to dist git. > > If I had time, I'd create automation that does this for me. Unfortunately I > don't and I follow https://xkcd.com/1205/ > > In what way does keeping the spec file in our fork help us? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
