[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: releases
From:       Thomas Zander <zander () kde ! org>
Date:       2007-07-08 7:10:21
Message-ID: 200707080910.25948.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 08 July 2007 00:23:21 Cyrille Berger wrote:
> Hi,
>
> I don't understand your first point :/ 

In KWord I picked up a TODO that I want to reinstate 'Find'. To search 
through all text.  In KDELibs there is a KFind and a KFindDialog. Both of 
these look nice, but are not unusable when you combine it with 
QTextDocument (which has find() methods).

This problem needs fixing; and there are two ways to fix it, either we add 
4 methods on the KFindDialog and some on the KFind class.
Or we copy the code and redo everything ourselves.  Now, we both know what 
the best way is on how to proceed and keep it maintainable code.

The thing is; the kdelibs freeze is rapidly approaching. So such fixes 
can't be made in time and you end up with a mess and lots of sad faces 
due to code duplication.

Thats why in my point one I stated that starting to use kdelibs classes 
should start as soon as possible.

> But I can't agree more with the 
> third point, 

:)


> As for the second, you can't expect people to start writting code
> release quality when the release is around nine monthes away ! 

I personally don't see why not. There are lots of people that do it like 
that.  And while there naturally is a bug or two in the code anyway, they 
get fixed faster and stay fixed longer.

> And for 
> myself, I have stopped trying to fix bug in my code, as very often, the
> bug is back a few svn up later, and then tracking + fixing again and
> again. So I only fix something that prevent to work on what I am
> working and I won't change my way of working until I am sure that I
> won't have to fix the bug again and again, which means I will start
> fixing bug when the project switch to the status "We are releasing soon
> !".

I personally would find that a very depressing way of working. Not 
something I'd be able to do for very long.
If something breaks again and again, you should really really be thinking 
on making it auto-testable. This way someone breaking your stuff can be 
shown that they were the ones who made the mistake and you can ask them 
to fix the bug that otherwise you end up fixing.
For example; I just yesterday noticed that an old unit test in flake 
stopped passing; and I can ask the guilty party to fix the code he 
changed some time back. And I'm sure he will.

The thing is, Cyrille, if you need the sources to be unchanging in order 
to make sure your code doesn't break, then I'm pretty sure that for the 
next release you will have all your features breaking again. So waiting 
for the last part of the release is only a short term solution. You do 
want your features to still be shipped regression free in Krita 2.3, I 
would think? :)

In the end; I see it as well, that a feature I wrote breaks after some 
time. It happens, nobody is perfect. But unit tests catch most of those 
and I'm a happier developer.

So, if you feel down about things breaking, do yourself a favor and learn 
how to write unit tests. You'll be a happier developer when you have your 
set of unit tests (and people to hit over the head who break your 
code ;) )
-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]