Council May Summary: Changes to ChangeLog handling

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Council May Summary: Changes to ChangeLog handling

Petteri Räty-2
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

On behalf of the council,
Petteri


signature.asc (918 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Council May Summary: Changes to ChangeLog handling

Mart Raudsepp-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Council May Summary: Changes to ChangeLog handling

pva0xd
В Птн, 20/05/2011 в 13:19 +0300, Mart Raudsepp пишет:
> 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

So, I just realized that we have to update Changelogs for everything,
whitespaces and comments included. Even after reading meeting logs I
still wonder, why council have decided to vote policy change that was
not supported even by minority of developers? The whole idea after human
editable ChangeLogs was to avoid whitespace changes and changes in
comments. In the current state it is possible to generate them on rsync
servers and avoid this burden.

I would like council to update policy to allow exclude whitespace
changes and changes in comments.

--
Peter.



Reply | Threaded
Open this post in threaded view
|

Re: Council May Summary: Changes to ChangeLog handling

Ulrich Müller
>>>>> On Mon, 30 May 2011, Peter Volkov wrote:

> So, I just realized that we have to update Changelogs for
> everything, whitespaces and comments included. Even after reading
> meeting logs I still wonder, why council have decided to vote policy
> change that was not supported even by minority of developers? The
> whole idea after human editable ChangeLogs was to avoid whitespace
> changes and changes in comments. In the current state it is possible
> to generate them on rsync servers and avoid this burden.

> I would like council to update policy to allow exclude whitespace
> changes and changes in comments.

I second this.

The council should also clarify how to treat the ChangeLog in case of
package removals. The devmanual requires that it is updated even in
this case, whereas the handbook says that all files should be removed.

Ulrich

Reply | Threaded
Open this post in threaded view
|

Re: Council May Summary: Changes to ChangeLog handling

Michał Górny-5
In reply to this post by pva0xd
On Mon, 30 May 2011 16:03:42 +0400
Peter Volkov <[hidden email]> wrote:

> В Птн, 20/05/2011 в 13:19 +0300, Mart Raudsepp пишет:
> > 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
>
> So, I just realized that we have to update Changelogs for everything,
> whitespaces and comments included. Even after reading meeting logs I
> still wonder, why council have decided to vote policy change that was
> not supported even by minority of developers? The whole idea after
> human editable ChangeLogs was to avoid whitespace changes and changes
> in comments. In the current state it is possible to generate them on
> rsync servers and avoid this burden.
So we're one step closer to getting rid of the whole separate log
burden and thus closer to clear git migration. And generating
changelogs on rsync servers is possible; egencache is capable of doing
that, though for git only.

--
Best regards,
Michał Górny

signature.asc (325 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Council May Summary: Changes to ChangeLog handling

William Hubbs
In reply to this post by Ulrich Müller
On Mon, May 30, 2011 at 02:23:09PM +0200, Ulrich Mueller wrote:
> The council should also clarify how to treat the ChangeLog in case of
> package removals. The devmanual requires that it is updated even in
> this case, whereas the handbook says that all files should be removed.

IMHO this is a case of common sense.

When you completely remove a package, the ChangeLog gets removed. End of
story.

William


attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Council May Summary: Changes to ChangeLog handling

Brian Harring-2
In reply to this post by pva0xd
On Mon, May 30, 2011 at 04:03:42PM +0400, Peter Volkov wrote:

> В Птн, 20/05/2011 в 13:19 +0300, Mart Raudsepp пишет:
> > 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
>
> So, I just realized that we have to update Changelogs for everything,
> whitespaces and comments included. Even after reading meeting logs I
> still wonder, why council have decided to vote policy change that was
> not supported even by minority of developers?
The majority support changelog maintenance for non-trivial changes;
meaning removals, additions, eclass/eapi changes, changing logic,
fixing build issues, etc.  That's not really arguable, and for those
who don't support it- they're bluntly, wrong, the ChangeLog isn't for
devs (we have vcs logs after all)- it's for users, and that's the sort
of thing they need to see.

The problem is, that's a *fuzzy* definition.  Quoting myself from the
meeting:

19:37 <@ferringb> Arfrever: the kicker is, in certain cases, you're
partally right.
19:37 <@ferringb> Arfrever: the reality is, people will just adhere to
the letter of the law rather than the intent
19:37 <@ferringb> we already had that occur with removal
19:38 <@ferringb> stupid that we have to essentially legislate common
sense, but that's what it is right now ;)
19:39 < NeddySeagoon> ferringb, common sense is much rarer that you
might think :)
19:39 <@ferringb> NeddySeagoon: well aware

If someone has a definition that is commonsense, then propose it- the
current "you must log everything" is very, very heavy handed and
basically was a forced situation since QA cannot make folks behave
when the rules are reliant on common sense.

We cannot have situations where devs adhere to the exact wording of
the rules but violate the spirit, which is exactly what got us into
this mess in the first place.

Proposals to refine changelog maintenance I'm definitely open to- I
very much hate that the situation basically forced us to go heavy
handed, but the reality is, w/out the rules QA can't do anything about
misbehaving folks- if they try, the argument becomes "I've not
violated any rules!".  If QA is able to make decisions/actions on
their own without mapping directly back to rules, offenders start
claiming "the cabal is after me, I've not done anything wrong!".

Basically, it's being stuck between a rock and hard place.  Not sure
there is a solution there either.

As said, come up w/ a proposal for that, closing the loopholes and I'm
very much interested; however you'll have a hell of a time trying to
define "non-trivial" in a manner that blocks people pulling
shenanigans.


> The whole idea after human
> editable ChangeLogs was to avoid whitespace changes and changes in
> comments. In the current state it is possible to generate them on rsync
> servers and avoid this burden.
>
> I would like council to update policy to allow exclude whitespace
> changes and changes in comments.

It'll be on the schedule.

~harring

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Common sense in (was Council May Summary: Changes to ChangeLog handling)

Andreas K. Huettel
Am Montag 30 Mai 2011, 23:55:52 schrieb Brian Harring:
> If someone has a definition that is commonsense, then propose it- the
> current "you must log everything" is very, very heavy handed and
> basically was a forced situation since QA cannot make folks behave
> when the rules are reliant on common sense.

Well how about "any change that can influence the behaviour of (portage|your
favourite package manager) in any way or present the user with different
output"?

Clearly rules out whitespace changes.

Small typos in text messages might be seen as a (harmless) borderline case.

Removal of an ebuild definitely can influence portage behaviour, as can f.ex.
an EAPI bump.

Thoughts?

--

Andreas K. Huettel
Gentoo Linux developer
[hidden email]
http://www.akhuettel.de/


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Common sense in (was Council May Summary: Changes to ChangeLog handling)

Diego Elio Pettenò
Il giorno mar, 31/05/2011 alle 00.05 +0200, Andreas K. Huettel ha
scritto:
>
> Thoughts?

LGTM
--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/



Reply | Threaded
Open this post in threaded view
|

Re: Common sense in (was Council May Summary: Changes to ChangeLog handling)

Brian Harring-2
In reply to this post by Andreas K. Huettel
On Tue, May 31, 2011 at 12:05:03AM +0200, Andreas K. Huettel wrote:
> Am Montag 30 Mai 2011, 23:55:52 schrieb Brian Harring:
> > If someone has a definition that is commonsense, then propose it- the
> > current "you must log everything" is very, very heavy handed and
> > basically was a forced situation since QA cannot make folks behave
> > when the rules are reliant on common sense.
>
> Well how about "any change that can influence the behaviour of (portage|your
> favourite package manager) in any way or present the user with different
> output"?

Mostly correct, although the problem there is 'influence'; consider:

src_unpack() {
  bunch of code
}

being changed into

new_func() {
  bunch of code
}
src_unpack() {
  invoke new_func
}

That should have no influence, thus not being ChangeLog'd.  The
problem is when the dev screws up, and it *has* an influence but no
ChangeLog.

A more real world example is people abusing eval and other things
(python eclass for example)- folks can/do argue that it has no
influence, but the complexity means it may have unexpected affect.

That's the crux of the issue, and it comes down to common sense.  
Come up w/ a sane policy for things like that and I'll owe you some
beer.

Either way, for the rest of it, as Diego said, LGTM.  I'm just
nitpicking here to make it absolutely clear to people where we start
running into policy issues.

~brian

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Common sense in (was Council May Summary: Changes to ChangeLog handling)

Ângelo Arrifano (miknix)
On Tuesday 31 May 2011 00:38:34 Brian Harring wrote:

> On Tue, May 31, 2011 at 12:05:03AM +0200, Andreas K. Huettel wrote:
> > Am Montag 30 Mai 2011, 23:55:52 schrieb Brian Harring:
> > > If someone has a definition that is commonsense, then propose it- the
> > > current "you must log everything" is very, very heavy handed and
> > > basically was a forced situation since QA cannot make folks behave
> > > when the rules are reliant on common sense.
> >
> > Well how about "any change that can influence the behaviour of
> > (portage|your favourite package manager) in any way or present the user
> > with different output"?
>
> Mostly correct, although the problem there is 'influence'; consider:
>
> src_unpack() {
>   bunch of code
> }
>
> being changed into
>
> new_func() {
>   bunch of code
> }
> src_unpack() {
>   invoke new_func
> }
>
> That should have no influence, thus not being ChangeLog'd.  The
> problem is when the dev screws up, and it *has* an influence but no
> ChangeLog.
>
> A more real world example is people abusing eval and other things
> (python eclass for example)- folks can/do argue that it has no
> influence, but the complexity means it may have unexpected affect.
>
> That's the crux of the issue, and it comes down to common sense.
> Come up w/ a sane policy for things like that and I'll owe you some
> beer.
>
> Either way, for the rest of it, as Diego said, LGTM.  I'm just
> nitpicking here to make it absolutely clear to people where we start
> running into policy issues.
>
> ~brian

Not disagreeing at all with what was said, I'm just going to add that adding
conditionals or exceptions to the rules makes them harder to remember. It is
easier to remember - you shall not pass - than - you shall not pass if you
make a change wich does not affect X - .

Regards,
--
Angelo Arrifano AKA MiKNiX
Gentoo Embedded developer
GPE maintainer
http://www.gentoo.org/~miknix
http://miknix.homelinux.com

Reply | Threaded
Open this post in threaded view
|

RFC: better policy for ChageLogs (was: Re: Council May Summary: Changes to ChangeLog handling)

pva0xd
In reply to this post by Brian Harring-2
В Пнд, 30/05/2011 в 14:55 -0700, Brian Harring пишет:
> The problem is, that's a *fuzzy* definition.

Ok, let's start with something and then we'll add more items if
required. Currently I'd like to propose following text:

The ChangeLog must be updated with each commit. The only possible
relaxations for this rule are:

1. Nonfunctional whitespace changes
2. Changes in comments (lines starting with # in ebuild, or leading text
in patches)
3. Manifest updates
4. Changes in ChageLog itself ;)

Something unclear? Anything else?

--
Peter.

text.xml.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: better policy for ChageLogs

Markos Chandras-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/06/2011 04:08 μμ, Peter Volkov wrote:

> В Пнд, 30/05/2011 в 14:55 -0700, Brian Harring пишет:
>> The problem is, that's a *fuzzy* definition.
>
> Ok, let's start with something and then we'll add more items if
> required. Currently I'd like to propose following text:
>
> The ChangeLog must be updated with each commit. The only possible
> relaxations for this rule are:
>
> 1. Nonfunctional whitespace changes
> 2. Changes in comments (lines starting with # in ebuild, or leading text
> in patches)
> 3. Manifest updates
> 4. Changes in ChageLog itself ;)
>
> Something unclear? Anything else?
>
> --
> Peter.
Maybe typos in e{log,warn,info} messages and/or typos in general (
variables, functions etc )

- --
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAEBCgAGBQJN5leTAAoJEPqDWhW0r/LCztAP/2GIXm1yllZX1r1IBErUoLGG
aO+8RGSgFrdT5SskyqA5Gbah+5XMzCyVEidebxst5JNSbpnKlRFPAvSJQUgHnJiD
+mQXizqqjJpbDBs0ktXFQIepXpUZ3vKUKAw8BG2fJ2thblBFA+A8V02cTF4mE5iV
HwiR2+0LGFVfR3HB2Q1Udbz24GIXxIFjhCzHW34f273VhBMWoUfaYxLAlFIPsnEn
TCvLwgdgSZqRIOH7+QyZHTVwvexVqHTu0mUWRTkCFoDX58PLfE4UolpRZGY/g/4n
MUDwmTvMaC7q90JhskCCCBcORgLnQpv4pqaTD6XV8x7Dnk96oT1BgDY7j5tu2Ezj
dp3ZPsPlf36xjYO9SGxu24KJvbb0DSeCxqN27EYa0p4yE/zAWyve2TsPX5lTdiVF
jZIrzoCBpBAu8/ggUBIDZOwgXMbHj2xTu2b1QFo2XOI+xSl57V+O5u2cuhEtQYYR
6kcK44cIYjKEUjroaxcn5CaIpOzmEuGq1O+1cNM+s7jXqPSQswa9EnJ5NyXs2IHw
EAOpqOpuQdNnk0cPqYv2zKhvTiP7Y6mR7aFA7zMOKPOD2Eh3E1BksPHk7hIKIjoS
nsVQ0f2sBntBUUmcc21QlPe5iSIuRrtj9hc3xiS2B4GygjiAflp443VL46ytjlH5
vlm5PBCN8ZZx0AvPc6n/
=Hnq4
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Samuli Suominen-4
On 06/01/2011 06:15 PM, Markos Chandras wrote:

> On 01/06/2011 04:08 ¼¼, Peter Volkov wrote:
>>  =4, 30/05/2011 2 14:55 -0700, Brian Harring ?8H5B:
>>> The problem is, that's a *fuzzy* definition.
>
>> Ok, let's start with something and then we'll add more items if
>> required. Currently I'd like to propose following text:
>
>> The ChangeLog must be updated with each commit. The only possible
>> relaxations for this rule are:
>
>> 1. Nonfunctional whitespace changes
>> 2. Changes in comments (lines starting with # in ebuild, or leading text
>> in patches)
>> 3. Manifest updates
>> 4. Changes in ChageLog itself ;)
>
>> Something unclear? Anything else?
>
>> --
>> Peter.
> Maybe typos in e{log,warn,info} messages and/or typos in general (
> variables, functions etc )
>

And the list will grow...

If we don't want to start monitoring also the context of ChangeLog entries,
Like if someone adds a epatch line to fix a real bug in a ebuild but
while at it fixes ebuild Coding Style for repoman/pcheck/and so forth,
fails to mention it in the log.
How is that different from committing just the Coding Style fix and then
leaving it out of ChangeLog?

Wouldn't it be better to just trust devs to use common sense in what
gets into ChangeLogs, and actually be grateful about if they take the
time to sensor the crap out from it, and scrap the whole topic?

(I honestly can't remember being involved in anything this useless...)

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Nathan Phillip Brink
In reply to this post by Markos Chandras-2
On Wed, Jun 01, 2011 at 04:15:31PM +0100, Markos Chandras wrote:

> On 01/06/2011 04:08 ????, Peter Volkov wrote:
> > ?? ??????, 30/05/2011 ?? 14:55 -0700, Brian Harring ??????????:
> >> The problem is, that's a *fuzzy* definition.
> >
> > Ok, let's start with something and then we'll add more items if
> > required. Currently I'd like to propose following text:
> >
> > The ChangeLog must be updated with each commit. The only possible
> > relaxations for this rule are:
> >
> > 1. Nonfunctional whitespace changes
> > 2. Changes in comments (lines starting with # in ebuild, or leading text
> > in patches)
> > 3. Manifest updates
> > 4. Changes in ChageLog itself ;)
> >
> > Something unclear? Anything else?
I think these are reasonable.

> > --
> > Peter.
> Maybe typos in e{log,warn,info} messages and/or typos in general (
> variables, functions etc )

But typos in variables and functions (which in most cases _imply_
functional changes) are generally bugs which should be mentioned in
the ChangeLog. Typos in informational messages (e{log,warn,info})
might also affect the user and thus be `functional' indirectly. I
think that the 4-item list is complete enough ;-).

--
binki

Look out for missing or extraneous apostrophes!

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Ciaran McCreesh-4
In reply to this post by Samuli Suominen-4
On Wed, 01 Jun 2011 18:27:04 +0300
Samuli Suominen <[hidden email]> wrote:
> Wouldn't it be better to just trust devs to use common sense in what
> gets into ChangeLogs, and actually be grateful about if they take the
> time to sensor the crap out from it, and scrap the whole topic?

This whole thing came about because a select few developers repeatedly
refused to use common sense, even after having been told to do so on
numerous occasions. Unfortunately, common sense for some developers
is running round the room whilst waving their wangs at everyone.

--
Ciaran McCreesh

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Andreas K. Huettel
In reply to this post by Samuli Suominen-4
Am Mittwoch 01 Juni 2011, 17:27:04 schrieb Samuli Suominen:

> Wouldn't it be better to just trust devs to use common sense in what
> gets into ChangeLogs, and actually be grateful about if they take the
> time to sensor the crap out from it, and scrap the whole topic?

The problem is, not everyone has the same notion of common sense. I hate fumbling around with cvs, and see it as an absolutely great convenience if the changelog clearly indicates when exactly an ebuild has been removed...

--
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
[hidden email]
http://www.akhuettel.de/

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Nirbheek Chauhan-2
On Wed, Jun 1, 2011 at 9:09 PM, Andreas K. Huettel <[hidden email]> wrote:
> Am Mittwoch 01 Juni 2011, 17:27:04 schrieb Samuli Suominen:
>
>> Wouldn't it be better to just trust devs to use common sense in what
>> gets into ChangeLogs, and actually be grateful about if they take the
>> time to sensor the crap out from it, and scrap the whole topic?
>
> The problem is, not everyone has the same notion of common sense. I hate fumbling around with cvs, and see it as an absolutely great convenience if the changelog clearly indicates when exactly an ebuild has been removed...
>

So we come back to the problem being *CVS* not ChangeLog rules.

All this is such a massive waste of time. Can't we just expend this
energy on the move to git?


--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Andreas K. Huettel

> So we come back to the problem being *CVS* not ChangeLog rules.

Well of course we can just tell everyone "go look it up on sources.gentoo.org".
However, this is a different discussion.

> All this is such a massive waste of time. Can't we just expend this
> energy on the move to git?

Ack, this is an idea that I can very much support. But please please then have the
changelog autogenerated from the git commit log, as otherwise the entire discussion
will just continue.
(/me is waiting for the next flamewar.)
And again, this is also a different discussion.

We're not talking about future plans here but about the current situation.
And about how to deal with it.

End of message from the department of redundancy department.

--
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
[hidden email]
http://www.akhuettel.de/

Reply | Threaded
Open this post in threaded view
|

Re: RFC: better policy for ChageLogs

Duncan-42
In reply to this post by Nathan Phillip Brink
Nathan Phillip Brink posted on Wed, 01 Jun 2011 11:30:21 -0400 as
excerpted:

> On Wed, Jun 01, 2011 at 04:15:31PM +0100, Markos Chandras wrote:
>> On 01/06/2011 04:08 ????, Peter Volkov wrote:
>> > ?? ??????, 30/05/2011 ?? 14:55 -0700, Brian Harring ??????????:
>> >> The problem is, that's a *fuzzy* definition.
>> >
>> > Ok, let's start with something and then we'll add more items if
>> > required. Currently I'd like to propose following text:
>> >
>> > The ChangeLog must be updated with each commit. The only possible
>> > relaxations for this rule are:
>> >
>> > 1. Nonfunctional whitespace changes
>> > 2. Changes in comments (lines starting with # in ebuild,
>> > or leading text in patches)
>> > 3. Manifest updates
>> > 4. Changes in ChageLog itself ;)
>> >
>> > Something unclear? Anything else?
>
> I think these are reasonable.

Agreed with one exception:

Under #2, changes in comment lines, please be specific that commenting a
previously uncommented line is NOT a simple comment change and thus not a
valid reason to apply this exception.  Otherwise we'll (unfortunately)
likely be having round #3 of the debate over someone arguing that
commenting an epatch line is simply changing a comment...

Perhaps (tho better wording is likely possible):

2. Changes in comments (lines starting with # in ebuild,
or leading text in patches, except that...)

2a. Commenting an existing line is considered more than
a comment change and thus must be changelogged.

>> Maybe typos in e{log,warn,info} messages and/or typos in general
>> ( variables, functions etc )
>
> But typos in variables and functions (which in most cases _imply_
> functional changes) are generally bugs which should be mentioned in the
> ChangeLog. Typos in informational messages (e{log,warn,info}) might also
> affect the user and thus be `functional' indirectly. I think that the
> 4-item list is complete enough ;-).

Exactly.  Plus...

The current "every change" policy goes overboard, I doubt anyone
disagrees, but it's worth repeating the point someone else made already,
every added exception makes the rule harder to remember.  The four
numbered exceptions (plus my proposed exception to the exception) above
are IMO a reasonable compromise between practicality and simplicity, but
getting much more complicated than that and... IMO it's better to stay
simple.

And in practice I believe it's impossible to define typos to the level it
unfortunately appears is now necessary, without either leaving holes big
enough to fly a jumbo-jet thru which no doubt someone will then attempt,
or complicating the rule beyond the point of simple effectiveness.  

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


12