Last attempt at reconciliation
mutz at kde.org
Wed Sep 18 20:59:20 BST 2002
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
> 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
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
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
> 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
The illegal we do immediately.
The unconstitutional takes a bit longer. -- Henry Kissinger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
More information about the kde-core-devel