On Fri, Jan 10, 2020 at 8:20 PM Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: > > On Fri, Jan 10, 2020 at 9:46 pm, Richard W.M. Jones <rjones@xxxxxxxxxx> > wrote: > > OpenSUSE proved years and years ago that dropping %changelog is > > possible, easy and desirable. We should do that IMHO. > > They still have %changelog at the bottom of each spec file, but as the > last line of the file. The actual changelog is stored as a separate > .changes file. That's a *lot* better than what Fedora does now, because > it makes it way easier to scroll through the spec file. But getting rid > of the changelog entirely would be even nicer. :) > openSUSE needs the changes file because the integrated VCS in their build system is awful. History is not able to be preserved across submissions to projects, so the only complete artifact of history is that file. If you want an example of a distribution that completely eliminated the management of an RPM changelog, look at Mageia (and its ancestor, Mandriva). Their Dist-SVN system dynamically generated changelogs from the SVN log. However, they had two properties that we don't have with Git, and we need some analogues for that: * Dist-SVN is still SVN, and that means the log data can be edited without editing the revision itself. This means the message could be changed after the fact and the next build would incorporate it. * Dist-SVN relied on tags of successful builds to track the checkpoints for changelog generation and did not use branches in any meaningful capacity, so the history was always fully linear. I think any successful equivalent of that for Dist-Git will require us to emulate these two properties somehow. My thinking is that annotated tags would be the right way to allow for changelogs to be set without the complexity of figuring out commit filtering. The annotation must be editable. If not, this won't work. We have to have a way to let people clean up changelogs. I think we can enforce linear tracking within a branch for Koji to generate Release values, but it's going to be tricky, given the contortions to the history that Git allows. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
