On Monday, February 12, 2018 5:59:57 PM CET David Cantrell wrote: > On 02/09/2018 08:34 AM, Josh Boyer wrote: > > On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > >> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote: > >>> It seems that a lot of people have %file, %check, %build, %whatsoever > >>> in their changelog section. > >>> Is there any reason I should not go and automatically escape them? > >> > >> This seems like a lot of churn. If we're going to do this, let's go big > >> and get rid of RPM changelogs. > >> > >> When we have a package update, there are basically two different kinds > >> of changelog information. Well, three. > >> > >> First, there's the upstream changelog. We don't generally do much with > >> these except maybe package as %doc. > >> > >> Second, there's package maintainer changelogs. These are really > >> redundant with the dist-git log. We don't really need this anymore. > >> It's just a chore. > >> > >> Third, though, there's end-user information. Why should a user care > >> *This* is redundant with bodhi update info, at least if packagers fill > >> that out, and it often also duplicates upstream changelogs, *and* it > >> often also covers things like "fixes CVE-####' also carried the > >> specfile changelog. > >> > >> This is neither most helpful for user *nor* ideal for packages. Why > >> don't we drop changelogs entirely in favor of 1) using the dist-git > >> logs for specfile maintainers and 2) providing the end-user information > >> in a different way. This could be through specially formatted log lines > >> going with the commit, or it could be simply in a standard separate > >> file (`fedora.user-visible-changes`). Optionally, it could include both > >> a high level end-user summary, and a detailed description for sysadmins > >> and the curious. > >> > >> Wherever it lives, this would be read by Bodhi, so there's > >> would be need to enter it more than once. And, perhaps a DNF plugin > >> could be made to read and display this information for systems > >> administrators. > > > > I fully support the removal of RPM changelogs. However, you've missed > > two cases: > > I will also add that I fully support removal of RPM changelogs. To me > it ends up being a very common merge conflict if you are trying to > backport patches to previous branches and we could fix that by > eliminating the changelogs entirely. I don't support full removal. If any automation goes into pipeline regarding %changelogs, please let users the freedom to write the %changelogs manually if they want. Even if I'm not probably good at it, I'm fine to write the %changelog entry, and resolve the merge conflicts (in case of changelog it is matter of less then several seconds with meld, similar to merge conflicts in Release tag). As an example, see at GNU upstream repos (e.g. tar, automake, ..) how they generate ChangeLog from git changelog (gitlog-to-changelog through `make V=1 ChangeLog` command). That really requires *a lot* of concentration during writing git commit messages, and reviews. Any mistake in commit message requires another commit with "patch" for gitlog-to-changelog output. Yes, if we'll have good protection against mistakes (push-reject policy for mis-formated git messages, so e.g. provenpackagers won't create patch work for maintainers), it would be nice _option_ which I would love to pick in many cases. Pavel > > 1) Rawhide, which doesn't go through bodhi > > 2) Fedora release upgrades, which don't go through bodhi > > > > Now, I would actually LOVE for Rawhide to go through bodhi but > > whatever. The release -> release upgrade isn't really solvable that > > way though. > > > > Someone else suggested changelogs could be inserted during koji build > > time. That would be interesting to look into. > > The dist-git changelogs are mostly noise and I would prefer better > organized information about impacts to users and developers. Like tell > me what things changed in the new glibc package, not that the glibc RPM > has been upgraded to the new release. I can figure out that part myself. > > Many projects include a NEWS file which summarizes the major changes and > fixes in a new release. This is usually nicer to consume than > changelogs. Sometimes the summarized changes are in another file. > Sometimes there's nothing like that. > > Maybe we could mark the relevant changes for that release in the %files > section. Like: > > %changes NEWS > > Like a doc macro. An 'rpm -q --changelog' would just pipe that file > through the pager. Or display the path or whatever. If a package lacks > a file like that, rpm -q --changelog could just return nothing. > > This also leaves open the option for package maintainers to create their > own summary files and package readmes, which could be expanded to > explain specifics about that software on Fedora. > > -- > David Cantrell <dcantrell@xxxxxxxxxx> > Red Hat, Inc. | Boston, MA | EST5EDT > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
