[Kolab-devel] Native server package, RPM for CentOS, RHEL

[Jeroen van Meeuwen (Kolab Systems)]

On 2012-02-23 15:19, Bernhard Reiter wrote:
> Jeroen,
>

Hi Bernhard,

> Am Mittwoch 22 Februar 2012 15:48:12 schrieb Bernhard Reiter:
>>    http://mirror.kolabsys.com/pub/redhat/kolab-2.4/
>>
>> there are more current community server packages for CentOS and 
>> RHEL.
>
> I wonder, what is the status of the mentioned packages in regards of
> stability and usefulness? As I see it el5?

This branch (product series 2.4, platform el5) probably runs the 
largest deployment to date. As such, its usefulness is tremendous, I 
would say, and its stability could be argued to be implied.

That said, however, it was created with this one deployment in mind, 
specifically. It is not set up in line with what one would expect from a 
traditional Kolab Groupware deployment. It is breaking many Kolab 
traditions, if you will.

For this particular deployment -the reason for a series 2.4, really- 
for example, user provisioning is done completely differently from what 
we're used to, Puppet configuration management prevailed over 
template-based generating of configuration files, and therefore its 
setup routines and configuration management have not evolved with the 
rest of the software.

> Would it be a good idea to also send an email to our users lists
> about the availability of the current Kolab Server Community with 
> Webclient
> native packages for RHEL and CentOS and ask for feedback?
>
> Most readers on the users lists are administrators,
> so their feedback could be useful even if the packages are not 
> optimal yet.
>

I'm inclined to encourage people to take a stab at anything that is 
closer to 3.0 than 2.3 is. This would definitely include the 2.4 series, 
which could be considered an intermediate release on our way to 3.0. 
That is to say a couple of things have been re-invented and re-developed 
(from the ground up), which naturally impacts feature-completeness and 
stability - in a sense.

It could, arguably, be considered superior to 2.3 in a number of ways, 
but users (developers, administrators) of 2.4, like I do, have to 
realize the series may not be as feature-complete as they expect, and 
changes a bunch of things they may have previously considered vital for 
their production environments.

I'm therefore also inclined to not encourage people to apply the way 
they are used to doing things to 2.4 - it would make me support parts 
that are soon to be historic relics, heavily distracting me from the 
vast amount of Kolab 3.0 tasks pending.

That said, I would rather have some help finalizing the various bits 
and pieces that make 3.0 complete for the relevant parts (and could 
therefore also make 2.4 complete), including but not limited to;

- defining the way we would wish to run a setup or bootstrapping 
procedure,
- defining the way we could scale our configuration management or 
integrate with existing configuration management suites, beyond the 
proverbial small ("localhost") Kolab Groupware deployment,
- documentation, documentation, documentation, (of MAJOR 
importance!!!),
- quality assurance (i.e. testing).

We (Kolab Systems) can provide (access to) resources that can help with 
any such endeavour.

>> Of course the wiki page http://wiki.kolab.org/Native_Packages
>> is out of date.
>
> @All, does someone like to help with the wiki pages?
>

Let's state this differently, perhaps.

Is there anyone who would like to help with documentation in general, 
Wiki-based or otherwise?

We are looking for people that can both envision how things are 
supposed to work (as opposed to how the bits and pieces work), and 
recognize whether or not it is currently working in such way (it is 
supposed to work) - logging bugs against the existing code-bases as you 
go, writing some documentation on how it's all supposed to work, and 
therefore, thereby, shaping the future of Kolab Groupware.

If anyone feels they do not necessarily have a "vision" (which, 
admittedly, is a strong word to use), but would like to help nonetheless 
- great! We also need people that document how things actually work[1]. 
Should you feel you do not have sufficient knowledge or insight in how 
things work, but you are / would be interested in helping out, #kolab is 
open for question and answer, and we'd all be more than glad to explain 
things until you are saturated and satisfied you understand those 
things.

All of this would typically happen with Kolab 3.0 features and 
functionality looming around the corner, as there's little point in 
documenting what is soon to become history.

Kind regards,

Jeroen van Meeuwen

[1] 
http://hosted.kolabsys.com/~vanmeeuwen/kolab-docs/en-US/Kolab_Groupware/2.4/html/Administrator_Guide/chap-Administrator_Guide-Combating_Spam.html

     Large parts of this documentation come from Wiki pages on 
wiki.kolab.org

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08