Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling

[Mart Raudsepp <leio@gentoo.org>]

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