On Fri, May 08, 2020 at 10:13:25PM +0200, clime wrote:
On Fri, 8 May 2020 at 20:05, Zbigniew Jędrzejewski-Szmek
> 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.