On Thu, Sep 26, 2019 at 05:14:59PM +0200, Fabio Valentini wrote: > On Thu, Sep 26, 2019 at 4:57 PM Jeremy Cline <jeremy@xxxxxxxxxx> wrote: > > > > On Thu, Sep 26, 2019 at 04:49:31PM +0200, Fabio Valentini wrote: > > > On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek > > > <zbyszek@xxxxxxxxx> wrote: > > > > > > > > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote: > > > > > Instead I prefer a clone of the master upstream git repo and maintain a > > > > > branch with patches cherry-picked into it. This is used to auto-generate > > > > > patches for the Fedora RPM, at the same time updating the patch file list > > > > > in the RPM spec. The only manual step is adding the changelog entry & > > > > > bumping release number. > > > > > > > > Quick note: this is essentially what debian does. > > > > > > Ugh. Can we please just agree that source-git (vs. dist-git) is almost > > > always a bad idea? > > > > > > > Can you expand on that? To me it is a much easier way to maintain > > packages, but I don't have tons of experience doing that and I'm > > perhaps not the "average package maintainer". Hearing other perspectives > > would be helpful. > > Sorry, I should have expanded on that short statement. > > I literally maintain hundreds of packages, mostly by myself (yes, > that's too many, but that's a problem that tooling can't fix). > I'd hazard to guess that 90% of these packages don't contain *any* > patches on top of an upstream release. So pointing the .spec file to > an upstream tarball is the *absolute easiest thing* possible, and I > don't want to have to deal with the upstream git repo contents for > these packages at all. > For another 9% of packages, I maintain a small set of local patches > (up to two patches or so), which I can "generate on the fly" for every > new upstream release (if necessary), and which is only a small amount > of work. > For the remaining 1% (about 2-3 of my packages), I maintain a local > git repository with branches for every release, where I maintain a > small downstream patch-set. This seems to correspond to a source-git > approach, and might be similar to what you're doing. > > So, to summarize: I just don't want the absolute edge case to become > the general case. It would make things *massively* more complicated > for me, and I guess that applies to the "average packager" in fedora, > as well. > Ah right, that makes a lot of sense. I can imagine automatically detecting the new upstream release, building that, and presenting the packager with a easy-to-review PR that you just click "merge" on instead of pointing the specfile at a new tarball. Some of these could (I think) be solved with quality tooling, but I don't see that kind of stuff appearing any time soon. I do think all these things would have to be addressed, though, and I definitely agree that the corner cases shouldn't drive the workflow. - Jeremy _______________________________________________ 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
