On 06. 05. 20 11:19, Tomas Tomecek wrote:
On Tue, May 5, 2020 at 6:16 PM Miro Hrončokmhroncok@redhat.com wrote:
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?
I just couldn't understand why you are asking me about source-git when you already track your downstream patches as git commits :D
Notable difference: the github.com/fedora-python/cpython repo is an implementation detail to the maintainer(s). E.g. I use it when I need to rebase the patches and there the "officiality" ends. I.e.:
1) I push --force in there with each rebase. (and yes, I tag the old HEADs, but that just me being a nerd)
2) Any nonpatch spec changes don't require this repo, nor the knowledge of it.
3) Drive-by contributors and provenpackagers don't require this repo, nor the knowledge of it.
4) No synchronization back and forth is needed. I use the repo to generate patches -> it's a tool, not a canonical source. If deleted/lost, it can be recreated from dist-git at any time.
5) In an unlikely event of a drive-by contributor needing to touch the patches, the repo is in broken state and I've made a conscious decision that this is an acceptable trade off, considering the (extremely sparse) history of drive-by contributors changing patches in Fedora Python package.
For me, this resembles the "explode sources, git init, git add ." approach on steroids, nothing more.