On Tue, May 5, 2020 at 1:04 PM 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. That's how we want to approach this. Make it completely opt-in while keeping the present workflow intact. > > 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'm sorry but I'm unable to comment here. > > 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? Well, having spec file upstream is still the ideal case (or at least utilizing the respective Fedora spec during the upstream development). Sadly, it's not feasible for many projects, so yes, we propose to have this intermediate place. Benefits? * One works with real source files and not with `SHA512 (nyancat-1.5.2.tar.gz) = 8eee5da8afacdbe8b6b5f6...` * I can easily pull commits from upstream if needed * I can also easily propose patches upstream from such a repository * Updating to latest upstream release is no longer such a pain - rebasing patch files is gone * I can work with the package as I was working in the upstream repository * When a contribution comes, I suddenly review real changes and not patch files > 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 > > 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? (speechless for like a minute) Don't you wanna create (S)RPMs out of that repository? Don't you wanna be sure that when you add a change to that repository it builds fine on rawhide and the latest stable fedora? Tomas _______________________________________________ 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
