[Kolab-devel] Fedora packaging

[Jeroen van Meeuwen (Kolab Systems)]

On 2014-01-28 14:21, Karel Volný wrote:
> Hi,
> 
>> Fedora 20 packages are, at the moment, only being built for 
>> Kolab:Development.
>> 
>> If somebody feels inclined to also have Kolab 3.1 available for Fedora 
>> 20, all one needs to do is ask.
> 
> Not sure about the interest among others, but since F20 is out ..
> 
> But if I'm going to play with packages to review, I'd rather install
> (and test) those being developed than from OBS.
> 

For us -- the patron of Kolab Groupware and vendor of services around it 
-- we have not just one canonical source of "upstream" changes.

The Kolab community is upstream for software development, but only some, 
and downstream to distributions when we need to go about installing our 
stack on a given platform.

One clear example is the Roundcube web client, a package that our Kolab 
plugins heavily depend on, provides certain capabilities some of which 
are in git origin master HEAD only.

We *clearly* can't demand of distributions they ship a git snapshot. We 
*clearly* cannot distribute our plugins without the base Roundcube 
package meeting the associated requirements. We *clearly* cannot make 
our plugins compatible with all versions of a Roundcube package that 
distributions ship.

As such, you need to remember we do not ship a stand-alone piece of 
software, but a product stream composed of various pieces of software, 
dependent on one another to ensure the actual product is somewhat 
functional.

As such as well, you need to remember that there's simply not enough 
man-power to continue support for a Kolab 3.0 deployment on Debian 
Wheezy, while we would also not be allowed to ship Kolab 3.1, or later 
on this year, Kolab 3.2 to Debian Wheezy.

Similarly, we would not be allowed to do so for Enterprise Linux 6 -- 
nor able to continue support for it.

On 2014-01-28 14:21, Karel Volný wrote:
> Well, in fact, I'm not sure why a project would want to provide
> packages for any distribution (unless that's what the developers use
> and maintain for themselves) - there are so many ...
> 

I hope the former paragraph answers your question.

>> Hence, if we release Kolab 3.2 with Fedora 21, while Kolab 3.3 would 
>> end up in Fedora 22, none of the other distributions are on anywhere 
>> near the same cycle.
> 
> I'd just resign on any attempts to synchronise.
> 

It's not about the attempt to synchronize at all, though.

What does that bring you, the community at large, Kolab consumers, or 
the vendor?

Imagine Kolab 3.0 was released as part of Debian Wheezy proper, and 
Kolab 3.1 was being submitted to Jessie, and Kolab Development to Sid.

By the time Jessie is released, we'd be at Kolab 3.4, possibly an even 
later edition, and you will still have to support Kolab 3.0 on Wheezy, 
if otherwise you were unable to distribute a more recent product stream 
to the platform.

Very much the same, if not worse so, applies to Enterprise Linux 6 
(through EPEL).

>>> As I see four review requests opened in Red Hat's Bugzilla for Kolab
>>> components, I suppose the idea of having Kolab in Fedora is not
>>> considered bad, but there isn't enough manpower?
>>> 
>> 
>> There's certainly not enough manpower. It's not like I've been 
>> slacking off since February last year [1] ;-)
>> 
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=812526
> 
> So ... the first thing I could do is to kick you to finish that one? 
> :-)
> 
> Any chance you are coming to Brno (e.g. for Akademy)?
> Can I promise you a beer? :-)
> 
>>> I'm willing to help in that case; if an effort to get Kolab into
>>> Fedora proper already started, could someone give me pointers where I
>>> could be most useful?
>>> 
>> 
>> The packages that have been submitted are largely stand-alone. Kolab 
>> requires them but they do not in and by themselves require Kolab 
>> (though admittedly roundcubemail-plugins-kolab is largely about kolab, 
>> it can use the SQL driver for the calendar plugin and tasklist so 
>> forth).
>> 
>> The packages I believe need to be included in Fedora are:
>> 
>>    http://obs.kolabsys.com:82/Kolab:/Development/Fedora_20/src/
> 
> so, looking at the dependency graphs, I'd think that pykolab could be
> the next step ... that doesn't seem to be like an easy one for the
> start :-/
> 

First things first -- run rpmlint over the package(s) that is/are in the 
OBS under Kolab:Development. What falls out of that can relatively 
simply be reviewed, fixed and submitted.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

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

pgp: 9342 BF08