[gst-devel] GStreamer needs a maintainer

[Thomas Vander Stichele]

Hi,

> Thomas:  An incomplete ChangeLog is misleading, and worse than no
> changelog.  If you have a plan to create a changelog that is
> demonstrably better than the output of cvs2cl, _complete_, and
> not too much additional burden to developers, I think you'd get
> a lot more support.  As it is, you have almost no support from
> developers.

I agree for a big part.  But I want it discussed.  Most developers are
used to reasoning "it's in my commit message".

Here are my issues with that. there is absolutely no 1-to-1 relationship
between "commits" and "actual atomic fixes".  By this, I mean that
people tend to commit a fix, then realize it doesn't work, or doesn't
build, commit another ifx, and then maybe end up doing a third one to
fix the previous two.  The commit messages for this sort of thing just
plain suck.  In general, our commit messages are mostly lazy, and it's
very hard to figure out the trail through them.  Believe me, I've tried
going back to stuff a few times recently based on them.

In a nutshell, commit messages tend to be too finely grained, going
below the "what functionality changes have happened when" level.
ChangeLog entries on GNOME projects are so good for finding what
happened when and who did it, that I can do nothing else than state that
"ChangeLog entries have the right granularity for finding this stuff"
and "the only reason it doesn't work out for us is our methodology in
doing it".

Basically, if an even larger project like GNOME with a lot more
developers on it prove that it works, then the only reason we can offer
for why it doesn't work for us is something like "we don't care" or
"we're too lazy".  Reasons that are fine, by the way, because if we
don't want to do it, the we don't.

But let's not pretend that our miserable excuse for an alternative that
cvs2cl is is a decent enough replacement.

Now, after the negative, the positive.  What can we do ?

Personally, I think it can't be too hard to establish some sort of
methodology to make this work better.  The real question is, what do we
want to commit to ?  If all of you are going to say "cvs commit messages
are fine for me, I don't care what people expect from us wrt. decent
changes information", then there's not much I can do, and I will let it
drop.

If, on the other hand, we as a project feel it's a worthwhile goal to
provide better change info to the outside, and we can come up with
something (be it a tool, a methodology, a set of agreements, whatever)
that does that if we all use it, I'm willing to put time into something
that works well for us.  And believe me, I know I will have to make it
as simple and idiot-proof as possible if I'm going to get you guys to
use it without it getting in your way.  Personally, I do feel that we
need to provide some decent log of changes to the outside, because we
make it REALLY hard on the outside to follow, and get a bad reputation
for it too.

So, let me know.  If you want me to put some time into this, that's
fine.  Just let me know if it's worth investing my time in :)

> Please, everyone, stop with the line of reasoning that starts with
> "If everyone did it my way, everything would be Just Great."[1]

I agree as well.  So if you don't want ChangeLogs, and everyone is ok
with it, say so and I let it drop and we delete ChangeLogs everywhere,
as a project decision.

My next question will be wrt. coding style, by the way :) I get sick of
our ten styles, and I feel we should just make sure everything is
machine-fixable and run it through indent.  To support your statement,
I'm going to start by saying "I don't care what the coding style is, but
pick one that works through indent and is consistent and has enough
spaces so we don't end up with stuff like if(a+5=2) b=9;else
printf("dumbass:%d\n",a);", and I'm not ever going to complain about the
style chosen after that.

Thomas