On Fri, 8 May 2020 at 20:05, Zbigniew Jędrzejewski-Szmek <zbys...@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? > 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 > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
