-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, 2018-02-08 at 13:32 -0500, Matthew Miller 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. While I totally agree with what you've said, there are some problems with generating changelogs from git. * Many times people put some useless messages in there, so we probably don't want to convert old history to git-based changelogs and have point where we ask people to start writing useful commit messages. * No easy way to map changelogs with versions and releases in package. Imagine that you pushed commit with update, then realised that it doesn't build and reverted. What should be in changelog? I would **love** to switch to git-based changelogs, but we need to work on defining how exactly it should behave and find way how to get there (it will involve release engineering at least). Would be nice if you would describe step by step workflow you would like to see 😉 In meanwhile, unescaped macros in %changelog create problems because they do expand. - -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp9SesACgkQaVcUvRu8 X0wPGQ/9E6PRloCCF3q945AVt+saxen2PG+ehvRRjUTPK2tmmQQDf5NzaGsVowF3 /RYwxNpCeiBUgy2mz0/3lfkRSGhvM6km5hT370LdTec0WE85Fd0MUWiYt8uPoL8q bUxDKpJl6H7gcEFslztP0Ou2W85RWUfGGOux03IZQdjssxDF+bCUX17VrHWaieFA o1u7Q/jFT6nYGA4F+hHOYF8eFzG7nT64ScJTXL/uJeHTiwT6pBWUm6yCKpl539tl 2+jozmKA/7GcuHopT7QaV51hlJ5nDy+mcAGhjRmYVxm5OIxAxICkegcKCL2FTbsm BKx70jrd4gb5ScsVUBGUTXgf9BUbUdXwMV2iCrLDiSyDSkOE9kooBifR4lLj7Asf /eldClCnOkcNeEzapfFvu6T3YDZaG6sVm64UcZ5UdfsJ+44HPE9MygCaicprnRdL HO8eSQwq7GDYL2i+XZWgXzon3w77u3DBMGYUxOz1tTTTBNiD/mr8EAqxC2gUsxfQ tCk8NjROmo0d0kqBGr7Fu1ltjVrB0rGx4CRlU/84O/Rt6G53ZWJ/s4+fa/QnhBCz FzVg/aOPc8+CZX6g+vXr5RJ5lo/oKErzT5hI29eev9oUOJulhA0zc04C9pa7X3tV 9tU6DRsjKLeth9u+ecyH+SOwwfMS8XGVZZ6b2hkFfMOAqqMTWps= =GWlO -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
