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

List:       kde-core-devel
Subject:    Re: Charles?!!!
From:       Rik Hemsley <rik () kde ! org>
Date:       2000-07-02 21:36:54
[Download RAW message or body]

#if Matthias Elter
> Sorry, but what about testing before commiting changes? Some people
> have other things to do than cleaning up behind you. This is not the
> first time you broke critical apps (your knotify loops in kwin come to
> my mind), please try to be more carefull or don't touch CVS.

Charles read the cvs manual before making any changes. He happened to make
a mistake, which was corrected. The CVS manual is not easy reading, and
it's easy to screw up.

> > Coolo did know about the branch we created.
> 
> Great! But what does this help to avoid duplicate work? I think you
> don't understand basic concepts of team work.

The intention was to quickly implement a couple of features. When we
dug further into the source we realised that kicker was designed in such
a way that implementing those features was harder than anticipated. By
this I mean that the object model was, can I say, not the best design.

We had assumed that with kicker being a fairly new app, the object model
would be clean and that the features we wanted to add would take only a
few hours.

> I have been working on multiple panel support, too. So much about
> avoiding duplicate work.

Of course we don't want to waste our time writing stuff that other people
have already done. With most of the Germans asleep and/or at LinuxTag, and
the lack of any mention of forthcoming multiple/corner panel support (see
kicker/TODO), we decided to give it a go.

> [...] You perhaps also don't care about the KDE2 status report mails
> mhk is posting to the lists but if you did you might know that we are
> close to feature freezing kdebase.

Of course we know that. That's exactly why adding features _now_ is
important, otherwise they won't happen for a long time.

> Sorry Charles but this is not the way KDE developement works. I think
> you should have learned your lesson after the radomString() story.

The way KDE development works is that anyone is free to contribute.
Creating a branch in order to hack in a couple of (apparently unplanned)
features (where the surgery will make the app unusable temporarily)
has got to be the most sensible way to go about this, don't you think ?

> P.S.: By the way, there is no need to make kicker a KApplication
> instead of a KUniqueApplication to debug it. Try '--nofork' next time.
> There is even less need for you to commit 'fixes' like this into CVS.

Into a branch created for two people to share code without having to set up
an rsync server or mail patches ? CVS was invented for this very purpose. 

I'm a bit upset that Charles is being targeted for abuse.

* It was not only him involved. Shout at everyone, don't choose a
  scapegoat.

* Are we supposed to make use of the CVS server or what ? The branch can
  be closed if it's not wanted, so where's the problem ?

* If you are planning features and you haven't mentioned them in the
  (existing) TODO file, don't complain when someone starts implementing
  the same features. And certainly don't complain when they end up being
  guilty of nothing more than wasting their own time.

Rik

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