On Thu, 27 Feb 2020 at 12:42, David Kaufmann <astra@xxxxxxxx> wrote: > > On Thu, Feb 27, 2020 at 12:21:48PM +0100, clime wrote: > > On Thu, 27 Feb 2020 at 10:00, David Kaufmann <astra@xxxxxxxx> wrote: > >> Another idea would be generating a changelog-entry from git history when > >> creating an update in bodhi, and there is no pre-existing > >> changelog-entry for the current version. > > > > But Bodhi changelogs is not what user can read on his/her machine when > > examining e.g. dnf check-update --changelogs. These are imho rpm > > changelogs. So the rpm spec changelogs are the most important. > > Ah, sorry, what I meant to say is bodhi modifying the .spec file, adding > the changelog line, and committing it, before building the package. > (similarly like the releng commits when rebuilding stuff for new > releases) > > But when I am thinking more about it I think it won't work, as bodhi > would need to rebuild the package then. (afaik it does not, as koji > built it already) Ah, right, I understand now. Thank you for the explanation! > > An alternative might be something like modifying "fedpkg build" to check > for missing changelogs and ask something like: > > "your package does not contain a changelog entry for <version>. should > we add the following entryies to the changelog for <version>?: <list of > commit-messages>" > > maybe even with the option of modifying the lines? That would be possible, yes, but then fedpkg build would need to create additional commit to maintain what user have inputed so that it is remembered somewhere and present in the resulting rpm, i.e. it would probably need to change repository and do a push during the build launching. I had a similar idea but executed earlier. When` fedpkg tag` is invoked (packagers usually don't invoke it today), a test-editor window is opened that can be prepopulated from commit message but it could also be prepopulated from an external file depending on configuration. Here user can compose the final changelog record for the given release and this record is then stored in the newly created tag (in its annotation) and from there it is automatically (through a dedicated macro if used) rendered into spec file when needed (e.g. when srpm is built). It requires one more step (i.e. fepkg commit -> fedpkg tag -> fedpkg push -> fedpkg build) but the build can be also launched automatically if a new tag is pushed so the number of steps would be the same. A disadvantage is that the spec file is not standalone with respect to important information. It can be, however, made standalone at any time by "rendering" it, i.e. process when the macros are replaced by the actual information pulled from git (the command to do it could be e.g. fedpkg spec). > > All the best, > Astra > _______________________________________________ > 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 _______________________________________________ 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
