Houston, we have a problem.

[Dirk Mueller]

On Don, 05 Sep 2002, Marc Mutz wrote:

> For those of you unaware of the current threa{t,d}s on kmail at kde.org:

...

> the basis of the feature freeze and on the basic principles of KDE 
> development.

> Since we couldn't stop Don from comitting and he obvously didn't even 
> consider opening a branch for his work (as suggested by myself quite 
> early on in the discussion[15]), I now appeal to the release dude to 
> speak up on this.

....

> It's not easy for me to do this, but failing any positive effect, I ask 
> to revoke Don's CVS rights at least until 3.1.0 is out of the door.

The short answer: No. 

The longer answer:

I'm very unhappy to see that you all try to escalate the conflict even more 
by doing such unreasonable requests. The worst thing that could be done 
right now is trying to solve this situation is by to enforcing our power 
over CVS accounts (I'm even more unhappy about seeing such requests from a 
wellknown developer and kde.org alias owner - different topic though). 

I can't decide if Don's patch is a feature or a bugfix and I don't think its 
my job to decide about it, because I hardly contributed a single line of code
to KMail. Those who wrote most parts of KMail will be able to judge much 
better, and I encourage them to explain their reasoning for their opinion. 

So, having read some of the discussions on kmail mailinglist it seems there 
are two issues, which are accidently confused and combined in this 
discussion. The first issue is, who is maintaining KMail and the second is 
if Don's change should be committed that late in the release cycle. I will 
not comment on the first issue, because this is IMHO an issue to sort out 
between all the KMail contributors, and not to be decided by anybody who 
isn't involved in the KMail development at all. 

So, the issue that remains is the question about wether or not his patch 
should be committed for KDE 3.1 or not at this time of the release cycle 
(The fact that it is already in CVS doesn't matter for me, it can be 
reverted at any time once there is a consensus).

This, however, is a conflict that can be solved on a pure technical base. If 
the patch causes more problems than it is worth, it should be dropped for 
3.1 release. If you think that reviewing and a little cooperation could make 
it work in time for the release, then by all means go for it. I very much 
miss this level of discussion in the threads I read on the kmail 
mailinglist, so I kindly ask you to reduce the conflict to this level for 
now. Please remember that we have another public Beta, which could very well 
be used as a reality check for the patch. I do understand that it will 
hardly make you detect all possible problems with the patch, but this is 
always the case. If you want to make sure that you don't introduce any new 
problems, better don't change anything in KMail. If you want to make sure 
that you develop KMail further to make it better than it is already, then 
actually _let_ the code be changed, review and test the changes and think 
about possible problems, and don't waste your time on putting more and more 
energy in this discussion. 

I believe that Don is reasonable enough to revert the changes if you 
actually point out the technical problems with it and explain why there is 
not enough time to fix them before the release. If you can't.. hmm. 

I would like to point out that I'm really trying to be impartial in this 
case, but seeing a bunch of developers who are angry (maybe for a 
reason, I don't want to deny that) about the commit from 
Don and are now trying to find a sort of "revenge", I can only speak for Don 
here and try to reestablish a balance that allows to find a solution that 
will be acceptable for everybody involved. Don't try to find a solution by 
testing who can shout louder. 


Thanks for reading, and thanks for understanding,


-- 
Dirk (received 944 mails today)