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