[bt-devel] Your changes in CVS

[Eeli Kaikkonen]

On Tue, 17 Nov 2009, Martin Gruner wrote:

> Hi Jaak,
>
> I just noticed that you made several commits to refactor the codebase.
>
> Just one day before a final release, this seems inappropriate to me. If you
> cannot _really_ guarantee that they don't break anything, please roll them
> back and apply them after wednesday again.
>
> Regards,
>
> mg

I agree with Martin. Also, if the commits are large, I would appreciate
some warning beforehand and description of what they do and why, i.e.
what's the problem they fix and how they fix it.

I know I have done quite large changes in the past without asking
anyone. But that was the time we didn't have releases and not everything
did work anyways. The codebase really needs refactoring but all
developers should be kept up with the changes and we should discuss as
much as possible. Otherwise it may happen that one developer can't read
the old badly structured code and replaces it with code which nobody
else can read. I don't mean that Jaak's code is unreadable, but it's a
common truth that people understand what they have written themselves
more easily than code written by other people.

For example, my code for creating module list trees was very small and
quite well documented (maybe nobody remembers the older code which
REALLY was a mess, different ad-hoc code everywhere where trees where
needed) and did what was needed and was flexible. Jaak replaced it with
model-view structure which itself looks like a good thing, but it showed
the exact reason why I didn't try to do it in the first place about year
or year and a half ago: I didn't feel it was worth it because it needs
quite much learning and complicated class structure and was an overkill
for our needs then. One simple class with a small helper class has been
replaced with more than ten classes. I repeat that the changes by Jaak
are not bad, on the contrary, but even if he finds it easy to read and
understand, I find it hard. And that's the case with any change made by
any developer. Therefore we need better documented code (and I can't
blame others for this!) and discussion before large changes.

Still another reason for discussing beforehand is that another developer
may have something going on with the same piece of code. It's quite
unpleasant surprise to notice that you are ready to commit a new feature
and just then you have to merge critical changes made by others and
start all over again.

But thanks, Jaak, for gearing towards better codebase. The need for that
is apparent and it's good somebody does something about it.

BTW, if the long time waiting for final realease is a problem, maybe we
could create a new 2.x branch before beta or rc? Then the head would be
open to larger changes.

  Yours,
	Eeli Kaikkonen (Mr.), Oulu, Finland
	e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)