[Kolab-devel] Freeze going for server 2.1.0beta

[Fabio Pietrosanti]

Bernhard Reiter ha scritto:

>Hi everybody,
>
>as you know Server 2.1 is really due.
>
>Our initial plan for getting is out did not fully worked out, because 
>a) we had to spend more work on security updates
>b) Key developers Steffen and Bernhard H. were not as available as wished
>c) We found more bugs that had to be fixed in 2.0.x, too.
>d) The wonderful work of Richard Bos and Markus Hüwe help to 
>    cleanup the implementation and make it even more modular
>
>For quite a few users, a server is needed that has the minimal 
>multi-email-user capabilities of 2.1 and the stability of 2.0.x.
>So our idea is to get 2.1 into that state soon.
>This also means we will not fix all bugs for it, nor move to OpenPKG 2.5.
>Basically we are in a freeze to get Kolab Server 2.1beta out of the door.
>Our plan is to do this within the next 7 days.
>Bernhard H. is working on it.
>
>This means: Critical bug fixes only. 
>                    Testing of new features and fixes that are already in
>		    and possibly fixes for them.
>
>Do we need a development branch for this?
>I am unsure about it. Actually I do not want to spread out the development
>of the server too much as a high priority is stability. Kolab already works in 
>many environments and we need to keep it this way, offering well testing
>upgrade paths.
>So my suggestion is to make the development branch, if server 2.1 can fully
>replace the 2.0.x servers.
>
>About OpenPKG 2.5: We believe this is a 4 to 5 days worth of work,
>but this is a place non-key developers can help:
>Try OpenPKG 2.5 on your platform, especially the packages that Kolab Server
>will use. Next try to integrate the patches and then build Kolab Server 
>packages.
>
>As always: report on this list!
>  
>
I suggest to switch to OpenPKG 2.5, it seems quite stable to me.

I would like to explain another very interesting feature which imho
should be part of Kolab's goal.

Kolab is a complete email systems other than a groupware platform.
It allow to really cut-down the cost to project, implement and maintain
an scalable email system.

To project because it already has a schema to manage the user base and
all well documented.
To implement because all the configuration files of every piece of
software that's part of Kolab are working immediatelly and are well
tuned for performance and functionality (configuring a
postfix/openldap/cyrus to get a good fully working configuration could
take months) .
To maintain because in kolab there are most maintenance scripts, backup
are coming, log rotate is working, etc, etc.
To be scalable because it allow to add systems to the infrastructure
with less than 1 hour.

I started using kolab because of a specific project for a customer and
now i'm starting to use it for all email systems i manage, even when i
don't need groupware functionality because of lower total cost of
ownership respect of other opensource email system integration.

I think that a lot of people are starting using kolab because of those
reason more than for specific groupware needs.

The needs for this class of kolab adopters are very good and granular
web administration and maintenance capabilities.

I think that a web administration interface based on Horde would be much
easier to do, maintain and expand for a lot of users needs.

Another good approch that kolab would do is to create a "Bounty page" to
allow people and company to submit feature requests and offer money for
specific feature.
This would allow the project to grow very fast.

Those are only my consideration on the project based on my experience
with Kolab.

Fabio

p.s. sorry for my very bad english