On Mon, Apr 08, 2024 at 12:38:47AM +0200, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > I'm revisting the topic of rpmautospec because I was doing some work > > on various packages, and it's annoying that some packages are using > > rpmautospec and others are not. > > The fix for that inconsistency would be to ban rpmautospec. It just makes > everything more complicated. > > > All my packages have been converted, so in day-to-day work, I don't > > even think about %changelog. When working with other packages, I'll > > forget to update the Relase and/or %changelog. Today I was rebasing > > some pull requests in pagure, and the _only_ conflicts that I had were > > about Release and %changelog. > > Generally, it helps to keep all your branches in sync [...] if you are building the same > versions for all releases (which is typically the one case where you bother > backporting specfile updates across releases at all), and to process pull > requests quickly, before you or rel-eng or another pull request bump the > specfile in Rawhide. Then you rarely have conflicts in %changelog to begin > with. Hmm, so KDE has an explicit exception for the updates policy, so that old releases can be updated and it's indeed possible to keep branches in sync. I _like_ keeping my branches in sync, but for most packages, this is not what is supposed to happen. And sorry, but saying to "process pull requests quickly" is just naive. Busy packages often have many different pull requests concurrently, and some of them need discussion and fixes and work in other places before they can be merged. > I mean, fast-forwarded to the exact same commit hash – no, it is not > a problem if the changelog for a Fedora release includes an entry > for a Rawhide mass rebuild made after that Fedora release branched, > it explains why the Release number has increased and is otherwise > harmless I find that distateful and annoying ;] It's also unnecessary, with rpmautospec and cherry-picking, you get a clean changelog. > > I think it's time to switch to rpmautospec completely. > > Thus, the proposal: > > - new packages MUST use rpmautospec > > - packagers SHOULD convert their packages > > - provenpackagers MAY convert existing packages > > (e.g. when they want to push some fix or separately from other > > work) > > - people submitting pull requests against src.fp.o MAY also > > include a conversion in the pull request and packagers SHOULD > > merge it. > > I am opposed to every part of this proposal. Allowing provenpackagers to > convert existing packages (that they do not explicitly comaintain) would be > particularly rude. I do NOT want any of this automagic (also the various > %auto* macros such as %autosetup) in my specfiles, it just makes my life > harder for no benefit whatsoever. I guess we'll just have to agree to disagree. In the other part of the thread, a proposal that was floated to allow opt-out. I hope that's acceptable. 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
