On Thu, 27 Feb 2020 at 13:23, clime <cl...@fedoraproject.org> wrote: > > On Thu, 27 Feb 2020 at 12:42, David Kaufmann <as...@ionic.at> wrote: > > > > On Thu, Feb 27, 2020 at 12:21:48PM +0100, clime wrote: > > > On Thu, 27 Feb 2020 at 10:00, David Kaufmann <as...@ionic.at> 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.
Actually, I thought about your idea doing it during `fedpkg build` (create the changelog record and push) and I started to like it more and more because people wouldn't need to run any extra commands compared to today when they would like to use the new macros. This could be only an opt-in feature (create_changelog_and_push_before_build or similar) cause some people will not want this. There are two ways how to create such record and push it without actually changing HEAD commit (which would be good cause otherwise we would be building different commit then we launched the command on, which would lead to confusion) 1) git notes: mutable text records that can be attached to any commit probably or tag in a git repo (see $ man git notes) and they have a separate history 2) git's annoted tags: tags with immutable text records and timestamps that can be signed and are checksummed. This is a direction of thought where the changelog is stored in git metadata. Proposal with the external changelog file in the repository is, instead, a direction where the changelog is stored in git data (well partially data and partially metadata because of the commit message fallback) - it's a bit different. Another thing to consider is whether we want a transparent build system where all the description of what will happen when a spec file is sent to it is included in the specfile itself or whether we want some auto-magic where e.g. 'Release' field or %changelog are automatically inserted when missing (something like that is impossible right now due to rpm constraints but just to make a point). > > 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@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 _______________________________________________ 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
