On Tue, Jan 28, 2020 at 02:25:33PM +0100, Florian Weimer wrote: > * Pierre-Yves Chibon: > > > On Tue, Jan 28, 2020 at 01:53:32PM +0100, Florian Weimer wrote: > >> * Pierre-Yves Chibon: > >> > >> > Feel free to poke at it and see how it behaves. > >> > > >> > The script only considers: > >> > - the last two years of commits > >> > - commits touching either the spec file or patches (ending with .patch) > >> > > >> > We want a way to say: [Ignore XXX] (or simply [Ignore] if it's the current > >> > commit that should be ignored), as well as a way to say: [Replace XXX] to be > >> > able to replace an existing commit message, but that's not there yet. > >> > >> Have you considered only auto-generating %changelog entries since the > >> last commit that changed the %changelog section? > > > > We thought about that, pull the last changelog from the last build, get the > > commit hash of that last build and only generate the new changelog from > > HEAD..<lastbuild>. > > The issue was: how to fix existing entries (typo, wrong content...) and our > > thought on this was that it would be easier to re-generate the entire changelog > > for this reason. > > > >> To fix entries, you would run a tool to materialize the current > >> auto-generated %changelog (and Release:), and then make the necessary > >> corrections and additions. > > > > Where would this corrections/additions live though? > > We were thinking to include the corrections in other/new commits but if we don't > > reach the old commits, we can't correct them. > > > > What did you have in mind? > > Sorry for being unclear. The spec file in dist-git would still show > some (older) version of the %changelog entries under this model. > > The corrections would update the %changelog with all the historic > entries. Since auto-generation stops at this commit, the new generated > %changelog will include the fixed entries. > > This would also avoid the need for a new knob to adjust how far back the > %changelog generation goes. Let me rephrase to see if I understand correctly. The changelog would be something like: `` %changelog %generate_changelog <The changelog up to the point the packager opted to use the macro above> `` This way we don't need to generate the old entries, we can just focus on the commits once the packager has opted in and not look at the old commits in the git history. Is that what you were thinking? If so I think I like it, if not I still like this but then I didn't catch what you meant :) Thanks, 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
