Raphael Hertzog writes ("Re: ChangeLog handling and git wrapper for
translators"):
> On Tue, 18 Dec 2007, Ian Jackson wrote:
> > * When we want complete and accurate commit history, use git log.
>
> For us, it's good enough. But generating a ChangeLog file doesn't cost us
> much and it can be useful to anyone doing "apt-get source dpkg".
Well, I don't mind if it's autogenerated.
> > * Ensure that debian/changelog contains human-readable and redacted
> > information. For simple changes `debcommit' does the right thing.
> > For more complex changes, perhaps ones which consist of several
> > commits, the debian/changelog can be written with coherent
> > information by hand.
>
> I don't always put in debian/changelog an entry for changes which do not
> impact directly what the users will experience (think simple code
> refactoring).
That's not too far from my approach. But I think it would be best to
at least mention it, because debian/changelog is the first place to go
looking for changes if something has stopped working. So just a
simple
* Refactoring of the frobnication arrangements
or if there is a lot of that kind of thing done
* Substantial internal refactoring, not intended to change behaviour
> In fact, I quite like to write the debian/changelog entry by explaining
> the user-side of the change, while the commit message is longer and
> explains the developer side of the change.
That's close to what I'm suggesting.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
