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

[Jeroen van Meeuwen (Kolab Systems)]

Gunnar Wrobel wrote:
> Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
> > 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/
> 
> Assume you'd be starting a "feature-x" branch in our current repo.
> With the solution you are proposing you will end up with having this
> branch in each of the component repositories. This has its downside,
> too.
> 

There's is always some sort of a trade-off ;-)

> > 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
> 
> I don't feel we need to keep these in a repository. But I think you
> are rather close to the cyrus upstream development, right?

Yes, I am. I do feel we need to keep work against an upstream in some sort of 
a repository, preferably one that keeps what is upstream and the patches we 
ship separate and in a shape that we can further develop/rebase frequently.

(..snip..)

> >> > - 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).
> 
> Ah, so you want to release a modified tarball for the patched
> components as well? Never thought about this and always assumed the
> patching should be done within the package definition. Actually I
> still believe this is better because it allows the downstream distro
> to decide whether they want to have the patches in the main package or
> not. Sure, we had problems to get the cyrus patches in in Debian or
> Suse. But they were available in the Gentoo package for example. If we
> release our own tarball then this wouldn't be possible anymore. Or at
> least harder.
> 

Yes, I would consider releasing tarballs whether they include the patches or 
not and whether they are actually applied within packaging or not; that's 
besides the case in point; 

If we patch foo we become upstream for that (did anybody say forked?) version 
of foo -at least for the receiving end of bugs we do. Foo packages would come 
from our repositories rather then RHEL's / Debian's. Tarballs with or without 
patches in one or the other contrib/, kolab/ or patches/ directory may or may 
not be included in such releases, or foo's version number may be amended. It 
all comes down to policy more so then the sensible approach to implement such 
policy with; without a clear policy anything else is pure speculation.

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