On Wed, Aug 19, 2020 at 10:46:48AM +0200, Pierre-Yves Chibon wrote: > 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).
In such cases it is often possible to just use another machine whose networking stack isn't busted to view the link. Even if this means using a smartphone. I think the value of the %changelog for debugging problems on a host is overstated in general though. In most cases I find the entries are just too terse to be useful, especially when you have packages where the only changelog info is "rebased to version x.y.z", with the actual useful info being in the release notes provided by the upstream project. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
