On 06. 05. 20 11:19, Tomas Tomecek wrote:
On Tue, May 5, 2020 at 6:16 PM Miro
>>> 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
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.