A hard decision

[Philip Van Hoof <spam pvanhoof be>]

Being a project maintainer you need to make certain decisions at certain
points in time. 

. . .

I have made such a decision a few seconds ago.



That decision is that the camel implementation of tinymail will from now
on always use libtinymail-camel/camel-lite, which is a highly patched
version of the Camel you'll find in today's evolution-data-server.

During the next days this copy (yes, copy) will be cleaned up. By that I
mean that compilation warnings and unused functionality will be removed.

I will also update all the documentation, take down the camel-lite-
builder trac pages. Building tinymail is of course a lot more simple
now: the normal ./autogen.sh && make works.

I will also significantly change a few data structures and I will soon
start reducing memory usage of the Camel pieces themselves. Especially
the folder-summary pieces. Having to keep supporting Evolution has been
really holding me back from going ahead with such changes.

Maintaining a patch and a builder (camel-lite-builder) isn't really the
right solution.

I have renamed the .so files and the include target directories. The
copy will not, not ever, conflict with existing Camel installations.
Tinymail, however, will also not, not ever, consider any existing Camel
installations. It will always, really always, use the camel-lite which
it ships and compiles. This can be reversed now, but soon tinymail
*will* depend on hooks and changes that *are* going to be introduced to
camel-lite.

I will try to get my work on Camel upstream. But note that copying a
version in my own repository allows me to make much more drastic
changes. Changes that will be indeed be very much required in a very
near future. It's highly unlikely that all of the changes will ever get
upstream. It's even likely that only a tiny fraction of them will.

Maybe some of the Evolution people or fans will blame me with the usual
bla bla about forking projects. But in fact evo devs do the exact same
thing themselves with for example libical and db. It's not really
something uncommon to do, and I don't want to keep trying and pushing
them to make or allow me making drastic changes in one of their core
libraries. I'm confident that experienced Evolution developers
understand this.

Evolution is not at the same development stage as tinymail. Tinymail is
in its experimental phase. Evolution is in its stabilization stage. It
has a huge amount of users to support. Its developers can't make drastic
changes to a core library like Camel. Tinymail, however, is very much in
its experimental stage. It wants experiments and therefore wants drastic
changes to happen. Also changes on libraries on which it depends, like
this Camel.

It's important for the survival of tinymail to perform experiments and
to push innovations. To allow ideas. To make that difference. To go for
it. To try it. And that way, to achieve results.

That's the reasons.

Feel free to disagree. But then please give me a real workable solution.

No anti-fork religion please. Real solutions is the only type of
discussion about it that I will maybe try to listen to.


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be