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.
--
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
