[gst-devel] new rules

[Thomas Vander Stichele]

El vie, 19-12-2003 a las 22:31, David Schleef escribió:
> On Fri, Dec 19, 2003 at 06:22:47PM +0100, Thomas Vander Stichele wrote:
> > (BTW, ds, I've used cvs2cl today to look at what changed between
> > releases for the release notes.  I thought it was horrible :) Given some
> > of the commits I did today as well that shouldn't really be in a
> > ChangeLog, I really rather would have no ChangeLog at all than one done
> > by cvs2cl)
> 
> Arguably, this is partly due to the fact that we often do terrible
> commit logs -- ones that cannot be understood out of context, a
> context which appears to vary by developer and mood.

Totally, but that is kind of my point.  cvs commit entries are tied to
what actually happens, while ChangeLog entries can be tied to what is
intended to happen.  Ie, if someone messes up a commit and takes three
commits to restore it, or commits pieces of patch all over in five bits,
then you get a bunch of entries with varying degrees of brevity in the
commit log.  While the ChangeLog would contain only one to the point
entry.

All I'm saying is that I think it's in the nature of commit logs to be
less carefully written than ChangeLog entries, with the same amount of
work.  Also, while ChangeLogs are conceptually tied to the act of making
the patch and verifying that the patch is correct (since I usually do an
update, then a diff, and the ChangeLog tells me what source files have
been touched BEFORE I commit), commit logs tend to get in the way of the
task at hand, namely committing.  Ie, I end up being annoyed at having
to type something just after I'm flushing the patch from my tree, that I
hastily make my way through the commit message :)

I haven't ever seen cvs commit logs that didn't contain lots of line
noise between the useful entries, while I have seen a lot of decent
ChangeLogs that tell me precisely what I needed to know; ie, which
changes made it in, pretending that they went in in one atomic
operation.

But hey, that's just me, whatever we decide is fine.  If we choose to go
with ChangeLogs (or, our maintainer du jour tells us to), I would love
to send out a mail with details on the tools I use that make me believe
ChangeLogs are great.  If we decide the other way, that's fine too, and
please let someone else then step forward to suggest tools and methods
to keep it as useful as possible.

Whatever's fine, let's just decide :) I've made my case, and wherever
you guys go I follow.



Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
And at the desktop there's cryin' sounds
For all the projects due and no one else is around
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/