On Fri, May 08, 2020 at 03:12:15PM -0400, David Cantrell wrote: > WHAT I WANT TO BE ABLE TO DO: > > * View Fedora's dist-git repos as authoritative for packages built for > Fedora. That is, I want to see a package on my Fedora system and be able to > visit its dist-git repo to see how it's packaged. Well said. > * Make the lookaside cache optional. For SourceX lines, I want to be able to > specify a git URL to a specific tag. fedpkg should use git archive to > include that in the SRPM. e.g.: > > Source0: https://github.com/rpminspect/rpminspect/archive/v0.12 Yes. This is somewhat orthogonal to the dist-git / source-git question. It would be absolutely great to have this right now on top of dist-git, so we don't need to do the step of 'amend Source0, spectool -g, fedpkg new-sources, git commit'. > * If we offer the above, honor signed git tags for verification at build time. > > * Make PatchX lines optional. In dist-git, I should be able to set a remote > pointing to the upstream repo. Then do the Fedora work on the appropriate > Fedora branch. SourceX should still become a tarball using git archive and > the tag. Patches should be automatically generated for SRPM construction > using git format-patch or something comparing the Fedora dist-git branch > with the remote branch. Hmm, but if we specify a git ref as source, why bother with patches at all? The step of generation and application of patches is error-prone, and if have a git ref, we have the tree object linked to it, and we should unpack that as the source dir without any further ado. > Multiple remotes should be possible should new and > old versions of the upstream project need to be supported. Fedora dist-git > branches should know their remote. > > * I still want to be able to do 'fedpkg srpm' and get a standalone > ready-to-build SRPM file that I can carry around. > > * Possibly extend fedpkg to helper package maintainers submit patches from the > package to the upstream project. Is 'fedpkg' the best place for this? Submitting PRs from a git branch is a very generic thing, and there's plenty of tools to do that already. And those tools might even be forge-specific. E.g. github has hub and now an official gh tool, and it's unlikely that fedpkg will ever do github PRs as well as gh. And when fedora patches are just a branch, then the generic tool can be used. > PRs in dist-git would be more meaningful to me if we were able to have the > upstream repo as a remote in dist-git and our branches just an extension of > that. Me likes. This would solve the perennial problem of "should I abuse proven-pakcager privs to do 'fedpkg new-sources' before submitting a PR?", which has two bad answers: "yes, and annoy the maintainer by polluting the cache if the PR is rejected", and "no, and have all CI fail". Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
