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. Tools like fedpkg and koji would need to learn to build a project directly from this git repo, building a tarball on the fly. (What smooge said about reliability: I wouldn't worry too much. 'git archive' is reliable, and we'd be doing this locally, so this wouldn't be too different from copying a tarball.) We then have a dist/source-git repo that is very similar to upstream, and we don't have yet another component in the system, but simple change how patches are represented in dist-git.
(Hybrid approaches like Debian's quilt model don't make sense to me: let's either use git or not use git, but doing both, and requiring people to much with patch files is no better than our current dist-git.)
Our aim is to provide the contribution experience you have in GitHub when working on your packages. Dist-git would still be the authoritative source and a place where official builds are done - the source-git repo would work as a way to collaborate. We also don’t have plans right now to integrate packit into fedpkg.
I don't get this. We need fewer (and better, more closely integrated) tools, not yet another layer of helpers for other helpers.
Zbyszek