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
