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