[Kolab-devel] Native Packaging, Issue Tracking & Restructuring the SCM

[Jeroen van Meeuwen (Kolab Systems)]

Gunnar Wrobel wrote:
> Hi Jeroen,
> 

Hey Gunnar,

> Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
> > Summarizing;
> >
> > - strong preference for separate repositories for Kolab components,
> > - proper product component versioning,
> > - branching/tagging policy,
> > - adjacent features in the issue tracker (roadmap, milestones),
> > - guidelines for handling issues in tracker,
> > - native packaging from tarball releases.
> 
> I can nod to all of that. Maybe there'd be some differences in the  
> details but I don't think that matters here.
> 
> So, yes, it is a sound direction ... BUT ;) I would say that we've  
> been on that road for quite some time now. How many "components" are  
> there that still hold actual source code? Just three: perl-kolab,  
> kolabd, kolab-webadmin. All other components are external and have  
> proper versioning.
> 

Very much true, these are the relevant components as they are in the 
repository now. I would prefer to have the perl-Kolab library on its own 
though, with kolab-conf being marked as part of the kolab-utils component.

If you look at the tree of a cleaned out perl-Kolab;

    http://git.kolabsys.com/kolab-perl.git/tree/

It becomes more clear why the utilities (many of which depend perl-Kolab, but 
not all of them) can live in a separate repository;

    http://git.kolabsys.com/kolab-utils.git/tree/

> So when I look at those three packages and you mention that the  
> component splitting would "inherently also force us to work with  
> proper, verifiable APIs"
> I can also nod and say that it would be great to have that. But take a  
> look at those packages and tell me if you see a quick way of getting  
> there.
> 

Essentially, this has already been done -even though it happened with a Quick 
& Dirty conversion/clean-out. The three components would be:

- kolab-perl (or perl-Kolab)
- kolab-utils
- kolab-webadmin

I would add to that, right away;

- kolab-archiver

For integration with archiving utilities, this is right now the simplest 
possible implementation of an archive.

- kolab-python

Or, Kolab Python libraries (pykolab site package).

And, currently at least, we do still have some outstanding patches to;

- kolab-cyrus-imapd
- kolab-php

Or, in other words, "the Kolab (patched) version of the upstream application", 
which we'll have to maintain for at least as long all supported platforms have 
fully integrated a patch to those applications we've submitted upstream and 
has been accepted there.

> > - proper product component versioning,
> 
> As mentioned we have that nearly everywhere and I actually only see it  
> missing for kolab-webadmin and kolabd.
> 

I wouldn't say we have proper versioning so much, as we're not maintaining a 
road map with milestones properly.

> > - adjacent features in the issue tracker (roadmap, milestones),
> 
> I think it is possible to do that in roundup.
> 

It's listed as a feature on the upstream website, but it does not seem to be 
enabled on issues.k.org.

> > - guidelines for handling issues in tracker,
> 
> I think it is possible to do that in roundup.
> 

It's possible in any issue tracker ;-) By guidelines I meant; "Ping someone in 
a bug and close it after 3 weeks of no response.", possibly a workflow for 
issue statuses, where someone like a release engineer looks over the ON_QA 
queue to 1) write test cases, 2) cherry-picks from/to branches, 3) maintains 
release notes if applicable for the change made, etc.

> > - native packaging from tarball releases.
> 
> I think most devs agree this is a desireable target for 2.3. Again we  
> are talking about two - three packages here.
> 

Not entirely true, I think; the patches we ship, or have shipped, are not all 
of them fully integrated upstream yet (php, cyrus-imapd), or have not yet been 
adopted in a released version of the distribution native packages. Or, 
sometimes, our product is not ready to handle by better implementing the 
required functionality (getgrent patch, ldap uid patch).

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