Last attempt at reconciliation

[Marc Mutz]

On Tuesday 17 September 2002 14:34, Don Sanders wrote:
> I have been thinking some more about my position.
>
> I would like to present Michael the following final offer at a
> compromise:
>
> I be allowed to fork KMail and begin work on KMail2 a mail client

A fork can't have the same name as the forked-from project. Calling the 
fork KMail2 would result in the rediculous situation that we'll end up 
with KMail 1.6's successor being KMail 3.0, since KMail 2.0 is already 
taken by the branch. Or something like that.

Imagine what we'd have now had xemacs been called emacs-20 instead.

> largely based on KMail but with the intention of making radical
> fundamental changes to the core architecture as I describe in
> my "Stuff I'm working on" mail.
> 
> Would that be acceptable?

Counter question: would _any_ solution be acceptable to you in which you 
do _not_ end up being the KMail maintainer in the long run?

I guess most people (me included!) would gladly welcome you back to HEAD 
as a valuable developer. Just stop thinking of you as being better than 
everyone else ("that bug is too trivial for me to fix", "I am the 
rightful maintainer").

Why do you _insist_ on forking? I see most of the changes in your branch 
being folded back into HEAD after 3.1. So do others, AFAIU. Is it so 
vitally important for you to become maintainer again? Why? If your 
solutions are good, you'll find the majority backing you. If your 
solutions are bad (or come at the wrong time), you'll find the majority 
calling for amendments to the patch (or postponing it). Don't you trust 
others? Do you need maintainer power to force in your ideas when you 
hit opposition?

When all this shit began, I asked you:
Q> Would _you_ surrender to a maintainer decision?

I fear the last weeks made it painfully obvious for everyone that the 
answer would be "no". Let's hope that is wrong.

> This would be somewhat similar to what my predecessor Stefan Taferner
> attempted.
>
> An example of where KMail and KMail2 would differ is that KMail would
> take the more conservative approach of embedding components like
> KOrganizer in it, while KMail2 would take the more radical approach
> of making a component out of KMail and embedding that KMail component
> in other applications.

I don't see that this is a difference evolving. I see no-one from the 
HEAD or the make_it_cool branch (or from the kdepim people, for that 
matter) agreeing on the kroupware solution. So how do you come to think 
that the make_it_cool solution will not be folded back into HEAD after 
3.1?

Marc

-- 
The illegal we do immediately.
The unconstitutional takes a bit longer.            -- Henry Kissinger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20020918/a763e602/attachment.sig>