On 05. 05. 20 18:12, Tomas Tomecek wrote:
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 followhttps://xkcd.com/1205/
In what way does keeping the spec file in our fork help us?
(speechless for like a minute)
I don't really understand this comment. Speechless because our workflow is tedious?
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?
That would be cool. I don't understand why do I have to keep the spec file in there for that.