Re: changelog format

[Karl Berry]

    *when* a rationale about the why and how of a changeset is to be
    given, the proper place for it is the commit message; so, *when*
    it's needed, it *must* go in the commit message.

1) [required] the wording must be such as to not assume/require the
existence of commit logs or shared source repositories at all.  GNU/rms
have never required any particular development methodology, and (in my
experience) he will reject out of hand any attempt to impose such.

In other words, add "if commit logs are used" to the beginning of your
whole thing.


2) [my opinion] I'm not sure I agree with the idea.  It is one way of
working, but not the only way.  For myself, I tend to write the
technical descriptions (including rationale :) in the ChangeLog, and
make the commit msg be just a one line hint kind of thing.  I actually
find that more useful when looking back at the commit logs than the full
rationales and details.

I realize full well that other people do other things, and that is fine.
Perhaps even your way should be recommended.  I don't think my way is so
horrible that it should be forbidden, however.  Aside from anything
else, it would be contrary to all but the most recent and "advanced"
practice.

karl