[Kolab-devel] Re: Fedora packaging

[Karel Volný]

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.

...
> Just waiting for the distribution('s community) to package our 
> software takes too long.
>
> Participating in every single distribution is too much effort 
> (as was building for each distribution separately, which is one 
> problem using the OBS solves) for any one given person -- it 
> would need to be a growing, collaborative effort.

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 ...

> These are not the main reasons to provide packages ourselves, 
> though. As you may be aware, bumping an .so-name is usually a 
> no-go in (otherwise "stable") distributions -- I use the term 
> "stable" lightly, because it's stable by policy in Fedora more 
> so than it is stable by bug-fixes only in (for example) Debian.

Talking about Fedora, with six months release cycle, I don't see that as an issue ... important security fixes usually don't require bumping, and features can wait until next release.

EPEL would be a different story, but I'd see that as a next step somewhere in the future that doesn't have to be thoroughly thought now.

> On the other hand, we have a release schedule (where's that 
> roadmap / agenda again?) that we can barely manage to complete 
> (see the level of incompleteness of docs.kolab.org).
>
> Long story short, when we release Kolab $x, we want to release 
> something people can install and play with (not flawless, nor 
> picture-perfect, nor without bugs) on their favorite 
> distribution (version).

Same as above, a few months delay because of different cycles seems okay to me.

(anyone can use rawhide packages anyways :-))

> 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.

>> * what are the possible reasons for not including Kolab in Fedora
>> proper - license issues, whatever ...
>
> No, no, no and no. We are *F*ree Software or I'd fire my own 
> ass and feel very depressed at failing in life's ambition.

Glad to hear that :-)

>> 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 :-/

> not including:
>
>    - cyrus-imapd (I can commit that myself, but the version in 
> Fedora is good too),
>    - libkolab, libkolabxml (already in Fedora, we just need a 
> more recent version -- note that KDE builds against this, and we 
> are an .so-name bump ahead).

isn't that time to upgrade it in rawhide to have it ready for F21?

K.

-- 
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol at jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."