On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote: > Questionnaire right at the beginning, so if you tl;dr, you don't miss it: > > https://forms.gle/Jgr13vtRkiUwLb6W6 > > This is no change proposal but rather a result of my long-term curiosity > around the $Subject problem. I hope I marked the results public so the > results are visible to anyone. > > ------------------ > > ATM, I know of at least those serious attempts to "automatize" the > %changelog maintenance and Release auto-bumping: [1, 2 and 3]. > > All those proposals are pretty complicated (I know, this is POV > statement), but some of them require significant changes in build systems > (like allowing the build system to back-push the generated stuff, building > the code variant which is not yet committed, so security problems, etc.). > > It's not easy to decide the preferred variant... :-) But let me feed > the xkcd 927 :-) .... here is another. Call it e.g. the "Trivial" (or > compromise) variant. > > > Release tag problem/proposal > ============================ > > Let's stop requiring Release bumps for each build. And let's put an > additional tag into Release, like proposed in [4]: > > "Release: 1%{?dist}%{?buildtag}" > > ... and let the build-system to put there an artificial (but increasing for > subsequent build IDs) value. When looking into rpmautospec this was one of the idea we thought about. There are a few downsides to it that made us go in a different direction: - Relies on the build system and cannot be emulated locally (without access to it) - Conflicts wit the minor release bump field of the versioning schema: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_more_complex_versioning IIRC the first one was the one that blocked this idea for us as it was mentioned on the list that people want to be able to build their RPM locally as close as possible from what the build system does. > The %changelog problem > ====================== > > IMO, all the burnouts and wasted time around %changelog is caused by those > things: > > a) we misinterpret what git-log is for, and what %chagnelog is for, but > b) we are still forced to properly maintain the %changelog, and > c) we have to duplicate %changelog in Bodhi Well, the bodhi update description should likely be the one most different from the other two. [..] > If we tend to answer yes, maybe we should rather go with something trivial as > this: > > %changelog > * This package doesn't provide changelog metadata, check it online > https://src.fedoraproject.org/rpms/<name>/commits/<last_commit> One of our requirement when we looked into this for rpmautospec was that the changelog should be accessible on a machine without internet (think: network stack is busted, I want to check what changed in the rpm of that stack). So while tempting this wouldn't fit. Pierre _______________________________________________ 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
