Re: [Kolab-devel] current state/future of debian packages ?

On 2015-01-14 16:44, Timotheus Pokorra wrote:
> Hello Matthias,
> 
>> what is the current state of the kolab debian packages?
> There are two goals that are very different:
> 
> One goal is to get Kolab into the Debian distribution. This is what
> Paul Boddie refers to.
> The other goal is to just install Kolab on a Debian installation, a
> dedicated server doing nothing else than Kolab.
> 
> The first goal is a huge task, and at the moment Kolab is far from
> reaching that goal.
> 

Let it be noted that, from where I'm sitting, inclusion in to upstream 
distribution's stock repositories is certainly a goal, but it is also 
not the highest priority.

Let me explain why -- and I speak from personal experience not 
hypotheticals or reputations; Upstream distributions;

   - have their policies for packaging, updates, and for what updates go 
where and what updates are considered upgrades.

   - may have policies surrounding the level of smoothness required 
between updates and upgrades.

   - may have their policies around what configuration mechanism to use 
for (at least) certain aspects of a system installed with their 
distribution.

   - have their own timelines.

   - may have chosen to ship everything that matters in a (large) set of 
"add-on" repositories -- of which Kolab would require many things.

   - may have mailing list software that is impossible / very much not 
efficient for us to subscribe to.

This is, in part, the reason why when you install (for example) iRony 
from the Kolab repositories, your iRony installation to access Kolab 
data over *DAV protocols becomes available under a /iRony/ URL (and not 
at / (on a vhost) so you get all the good stuff).

This is not to say policies are bad... They're all well-intended and for 
a greater good. But, ...

In part this is a problem because, with regards to the timelines of 
individual distributions, their update policies or their maintainer(s) / 
point of contact may not allow / indulge us to have a sufficiently 
up-to-date python-icalendar that we require for certain functionality in 
Wallace to function. I mention this as an example because we contributed 
some fixes and enhancements to python-icalendar upstream.

Libraries such as libkolabxml and libkolab, that are shared between KDE 
PIM and the Kolab server components form another conundrum. We tend to 
not be allowed to ship two versions (such as may be needed for one given 
Kontact release vs. a new Kolab release) in parallel and/or label 
installing/running KDE PIM and a Kolab server as mutually exclusive for 
a certain installation.

In another part this is a problem because, with regards to such 
problems, for example Kolab 3.4 would need to wait for Debian Jessie to 
actually be released, rather than be released in February. That is not 
to put Debian in a bad light -- similar obstacles arise with different 
distributions. The point is that you can see how waiting for and/or 
actively contributing to and/or coordinating with what you consume 
amounts to:

   - EPEL for CentOS / Red Hat Enterprise Linux 6
   - EPEL for CentOS / Red Hat Enterprise Linux 7
   - Fedora 20
   - Fedora 21
   - Fedora Rawhide
   - Debian Wheezy
   - Debian Wheezy Backports
   - Debian Jessie
   - Debian Sid
   - openSUSE 12.3
   - openSUSE 13.1
   - Ubuntu 12.04
   - Ubuntu 13.10
   - Ubuntu 14.04
   - Ubuntu 14.10
   - Ubuntu vivid (presumably 15.04)

And that is not to mention the third-party upstream projects! The 
projects we are ourselves upstream for would come to a dead stop for a 
few years -- this thing called "Kolab" among them.

To name but two examples, Enterprise Linux and Ubuntu LTS releases are 
supported for several years. Debian releases reputably spend multiple 
years being the "stable" version despite ever so ambitious plans to 
stick to timelines set out for a given "testing" to become the new 
"stable".

I'm perfectly willing to entertain the community maintaining a given 
Kolab x.y release for longer periods of time, and I'm willing to help 
where I'm needed, but we have to acknowledge that's not well within our 
reach at this moment.

What the Kolab community needs here is a champion -- one for each of the 
distribution streams at that, I suppose. I'm familiar with Aeneas 
Jaissle championing the openSUSE camp for example, which, I'm being 
told, works very well for Kolab users on openSUSE. In the Debian world, 
we have Daniel Hoffend and Timotheus Pokorra championing the packaging 
-- through our own OBS for now, and for fixes more so than policy 
compliance I believe --  while others champion packaging Kolab for 
inclusion in to the Debian stock repositories.

These efforts elsewhere sometimes result in contributions back to the 
upstream project, but more often than not result in derivatives. 
Sometimes minor packaging tweaks compared to what we ship, sometimes 
major overhauls of entire application suites, sometimes through a slew 
of bash scripts considered supplemental. As such it is often 
(relatively) (much) hard(er) for these third party efforts to update 
their packaging to a newer version of Kolab -- which is not to say it is 
ever so smooth when new packages are submitted to Kolab:Development.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +41 79 951 9003
w: https://kolabsystems.com

pgp: 9342 BF08