From kmail-devel  Wed Sep 18 19:59:20 2002
From: Marc Mutz <mutz () kde ! org>
Date: Wed, 18 Sep 2002 19:59:20 +0000
To: kmail-devel
Subject: Re: Last attempt at reconciliation
X-MARC-Message: https://marc.info/?l=kmail-devel&m=103238026314324
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--Boundary-02=_fsNi9oL2HLm5d8g"


--Boundary-02=_fsNi9oL2HLm5d8g
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

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=20
fork KMail2 would result in the rediculous situation that we'll end up=20
with KMail 1.6's successor being KMail 3.0, since KMail 2.0 is already=20
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.
>=20
> Would that be acceptable?

Counter question: would _any_ solution be acceptable to you in which you=20
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=20
as a valuable developer. Just stop thinking of you as being better than=20
everyone else ("that bug is too trivial for me to fix", "I am the=20
rightful maintainer").

Why do you _insist_ on forking? I see most of the changes in your branch=20
being folded back into HEAD after 3.1. So do others, AFAIU. Is it so=20
vitally important for you to become maintainer again? Why? If your=20
solutions are good, you'll find the majority backing you. If your=20
solutions are bad (or come at the wrong time), you'll find the majority=20
calling for amendments to the patch (or postponing it). Don't you trust=20
others? Do you need maintainer power to force in your ideas when you=20
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=20
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=20
HEAD or the make_it_cool branch (or from the kdepim people, for that=20
matter) agreeing on the kroupware solution. So how do you come to think=20
that the make_it_cool solution will not be folded back into HEAD after=20
3.1?

Marc

=2D-=20
The illegal we do immediately.
The unconstitutional takes a bit longer.            -- Henry Kissinger

--Boundary-02=_fsNi9oL2HLm5d8g
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9iNsf3oWD+L2/6DgRAvv7AJ9vAH3P2rZNvmfm5tIIra3BrSwZEACg8ARm
+BiB5wDiwsXq+V90PSbOrlk=
=RvHN
-----END PGP SIGNATURE-----

--Boundary-02=_fsNi9oL2HLm5d8g--

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail