[pkg-kolab] cyrus-imapd 2.3.16

[Jeroen van Meeuwen (Kolab Systems)]

Mathieu Parent wrote:
> > Thirdly, with regards to cyrus-imapd-2.3.x, what is your opinion on 
pushing
> > such to -maybe- Debian unstable/experimental, provided someone is willing 
to
> > do the packaging work?
> 
> Currently we have kolab-cyrus-imapd (see note [kolab-cyrus-imapd])
> which is based on [cyrus-imapd-2.2] plus some patches (this is done
> with a [script]).
> 
> cyrus-imapd-2.3 is packaged out of debian by the Debian Cyrus Team
> (<pkg-cyrus-imapd-debian-devel at lists.alioth.debian.org>), but
> unfortunately it was not ready for squeeze freeze ([cyrus-imapd-2.3]).
> 
> Ask there if they want to take the remaining kolab patches. If not, we
> will still need to carry them in some kolab-cyrus-imapd-2.3 package.
> 

Will do, I've just subscribed to the list you referred to.

I have no objection against shipping a kolab-cyrus-imapd package. I'm working 
close with upstream Cyrus to Make It All Happen(TM), and in development for 
Kolab to Make Other Things Happen(TM). The reason I'm saying this is because 
we ship a kolab-cyrus-imapd RPM for those other distributions we support as 
well.

> > That said, speaking for Fedora / Red Hat / CentOS / EPEL, in which realm I 
am
> > a very much experienced packager, one of the obvious truths is that kolab-
> > cyrus-imapd simply won't be allowed in the sense that it is essentially a 
fork
> > for cyrus-imapd and the philosophy is to submit the work upstream before
> > including it in the distribution or repository.
> 
> This is the long-term goal of course. A mid-term goal would be to
> include those patches in the standard cyrus-imapd-2.3 package (which
> is not yet in Debian). A short term would be to finish cyrus-imapd-2.3
> and build kolab-cyrus-imapd-2.3 from it.
> 

I'll be taking some of the patches currently in kolab-cyrus-imapd upstream or 
+1/+0 them if they have been already, and start "porting" them to the RPMs we 
distribute.

> I have seen your threads on kolab-devel to merge kolab patches
> upstream. Keep going!
> 

Thanks ;-)

> > That being as it may, I would appreciate your feedback on anything that I 
do
> > for Kolab Systems that is somehow mutually exclusive with the APT 
packaging
> > guidelines -in which you are and probably will be for a long time to come,
> > much more experienced then I am. I would want to work on making what is 
part
> > of my job and your awesome work as easy as possible for you all.
> >
> > Point in case is also, that since pkg-kolab is a Subversion repository, 
I'm
> > unable to push out my work somewhere you can find/consume it, such being a
> > different repository over at Kolab Systems infrastructure. I regret that, 
but
> > I hope you will appreciate that I'm doing what I can ;-)
> 
> This is not a problem: Use git-svn and publish your work as you do on
> git.kolabsys.com. I will take a look at it and push as much as
> possible
> 

I actually just made it a git-buildpackage repository as well as I could, 
importing the latest .dsc having build that from Subversion pkg-kolab/kolab-
cyrus-imapd/trunk/. I think that allows either of us to work with the (sets 
of) patches?

Now that you've mentioned cyrus-imapd-2.3 as a package, I'll take a closer 
look as to what seems reasonable for the work to continue.

> > If you are interested, please let me know. Here's a couple of resources in
> > relation to our APT packaging efforts;
> >
> > http://git.kolabsys.com/apt/kolab-cyrus-imapd/
> 
> I think you would better start from current SVN cyrus-imapd-2.3 as a
> lot has been made there to follow current good practices. Also
> pkg-cyrus-imapd-debian-devel team need help.
> 

I'll have a look-see at cyrus-imapd packaging as well. If they could use help, 
I'll allow myself some one-on-one quality time with that package - wine, 
candles, the lot, you know ;-)

Kind regards,

-- 
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08