[Kde-games-devel] Fwd: Re: KGoldrunner update

Ian Wadham ianw2 at optusnet.com.au
Mon Apr 27 05:23:01 CEST 2009


On Sun, 26 Apr 2009 9:56:54 pm Stefan Majewsky wrote:
> On Sonntag 26 April 2009 05:36:45 Ian Wadham wrote:
> > Also, I found that the new Curse of the Mummy game was not
> > getting installed (an omission in CMakeLists.txt).  What!  And
> > none of you noticed? ... ;-)
>
> ... this case shows that we do not do enough regression
> testing. If I recall correctly, Eugene tried to make some testing
> initiative around the time when 4.2 was released. Perhaps we could issue a
> bug day together with the bugsquad, to get people to test our games? After
> all, games testing is fun if communicated correctly.
>
What it shows, IMHO, is that one can commit, announce and blog about
a new feature, but nobody feels obliged to give it a whirl until release time
or after ... and maybe not even then ... and why should they?  This is the
FOSS world.  People mostly work in their spare time and make their own
choices.  Just because Steve Mann and I think Curse of the Mummy is the
bee's knees, does not mean anyone else at KDE Games has to agree ...
Anyway, they are all busy working on their own games ... :-)

Nevertheless, we at KDE Games do have a duty to our public, I believe.

In a classical programming shop, the kind of problem we have here is taken
care of partly automatically and partly through formal "integration testing",
maybe by a formal testing team.  In other words, each programmer is
responsible for "unit testing" his or her own work, but when it is inserted
into the project pool, other programmers come to use it and rely on it and
they will pick up problems before the system gets to the client.  When they
find a problem, they simply wander over to the author's desk and ask to
get it fixed, which usually happens quite quickly.

We have "trunk", but that only ensures that things compile and build in
various environments, which is not much of a test.  Also, although all the
KDE games are in one "module", they are not a system of interdependent
parts - not like a commercial order-entry system, for example.

I suggest we in KDE Games can overcome this problem quite easily if each
of us has at least one "buddy" who peer-reviews and tries out our latest work,
regardless of whether other programmers in KDE Games find the changes
interesting and try them out for themselves.  This system would also help
overcome issues of style, library-usage and user-interface design before
they go too far.

So who will be my buddy?

Cheers, Ian W.




-------------------------------------------------------


More information about the kde-games-devel mailing list