On Fri, May 08, 2020 at 10:13:25PM +0200, clime wrote:
On Fri, 8 May 2020 at 20:05, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Hi, I'm a bit late to the party, but here's my 2¢.
On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote:
In the packit project, we work in source-git repositories. These are pretty much upstream repositories combined with Fedora downstream packaging files.
I think source-git would be an interesting avenue to explore... There's some hairy issues to figure out wrt. to rebasing of downstream-only patches, but if that is solved, there would be great potential to make certain styles of packaging much nicer.
For more complicated projects, rebasing of patches would require some git wizardry, but we'd reap the benefit of how good git is with rebasing patches. From the workflows people described, it is clear that many of us are doing some variant of a custom git branch to make rebasing easier, building custom tooling around that.
Would there be an interest within the community, as opt-in, to have such source-git repositories created for respective dist-git repositories? The idea is that you would work in the source-git repo and then let packit handle synchronization with a respective dist-git repo.
I agree with what Miro and others said about this: this brings a lot of complication. I expect requirement to have synchronization both ways is going to be a constant source of problems. We lose the invariant that dist-git is the canonical source of truth. (Automatic synchro is OK if it's just one way, but here it clearly needs to be both ways because some maintainers would modify source-git and other maintainers would modify dist-git.)
IMO, source-git as a third repo in between the project and dist-git is not useful. Instead, it would make sense when integrated with dist-git.
I am curious. Zbyszek, what do you mean by "integrated with dist-git", here?
Clone the upstream repo, add a fedora-specific branch, in that branch add the .spec file and whatever else we now carry in dist-git. I.e. use a single repo for both the source and the packaging in native git form.
Zbyszek