On 05. 05. 20 18:12, Tomas Tomecek wrote:
* 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
> 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
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.