On Tue, 5 May 2020 at 13:06, Miro Hrončok <mhroncok(a)redhat.com> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org