Hello, On T, 2011-05-17 at 13:32 +0300, Petteri Räty wrote: > http://www.gentoo.org/proj/en/council/meeting-logs/20110510-summary.txt > > Please note that you must now update ChangeLog with each commit. For > more information please see the meeting log and the preceding mailing > list thread: > > http://www.gentoo.org/proj/en/council/meeting-logs/20110510.txt > http://archives.gentoo.org/gentoo-dev/msg_eaefa325b31360324d0fe53d0b9071e6.xml
While I always was, and still am quite a strong proponent for ChangeLogging removals, does this mean I need to spam the ChangeLog for small or negligible affect mistakes and fix it probably even before any rsync master updates have gone by, while said fix is more or less covered by the previously committed ChangeLog entry of the same date? To make it more clear, here's an example from the past: I didn't have scripts for gstreamer split bumps before, and it was an unwritten rule back then that for one of them I forget to edit the required gst-plugins-base version in the ebuild to its new requirement before repoman committing, and notice it within 5 minutes of committing. Then I would just fix it up, and commit without a ChangeLog update (as it's just noise to curious users), as the correction to the required version is part of the "Version bump" work; plus the nature of the packages is as such, that almost completely surely the new enough gst-plugins-base version will be on the users system anyway, as other new versions of the (more widely used) splits got it correctly earlier on the first commit. So am I required to ChangeLog such trivialities too now? There seems to have been a slight discussion about typos and whitespaces during the meeting, but I didn't see any conclusion on a cursory reading and then it was just voted "strict". As a separate note, I'm also a strong proponent of writing in ChangeLogs a bit about what has changed upstream for a version bump, so that users can see the important things BEFORE upgrading (and having /usr/share/doc/${PF}/NEWS* readily available); of course until that doesn't significantly delay the version bumps themselves due to potentially increased work for the maintainer. -- Mart Raudsepp