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

Thu Sep 9 10:49:28 CEST 2010

Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

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

I didn't take a close look at the repo now but it makes sense to me to  
split this into a library and a utilities part.

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

I'm less concerned about the actual file structure and/or the source  
packaging. I'm fine with keeping the components separate. That does  
not change the fact that the components are highly coupled though. The  
key element is usually LDAP and configuration there. Once you start to  
modify something in that area the current code usually forces you to  
touch kolabd, perl-kolab and kolab-webadmin. There is nothing like  
what I'd consider a decent API in between there that would help in  
decouple these components.

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.

Still I'm not saying that we shouldn't do this. We want to move into a  
direction where there is looser coupling between the components. So it  
is okay for me to split it up now to indicate that even if there might  
be a little bit of maintenance overhead.

> 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? So it might  
make sense for you to rebase the patches often. What I did so far was  
to have a small Makefile that allows me to rebase the patches to a new  
release (see  
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/imapd/patches/).

But I'm not particularly attached to this way of maintaining them.  
What I want is that it is clear for the native packagers where the  
patches are available. They should be available directly and not by  
diffing branches or some such. The version they apply to also needs to  
be obvious.

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

I assume we are going to provide this soon, aren't we? ;)

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

Yes, we should definitely write this down somewhere and discuss it  
once here. There are some pages in the wiki and these should be  
extended to clarify the processes. I should extend these but feel free  
to add your suggestions there, too.

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

Cheers,

Gunnar

>
> 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
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>

--
Gunnar Wrobel
Developer, Kolab Systems AG

e: wrobel at kolabsys.com
t: +49 700 6245 0000
w: http://www.kolabsys.com

pgp: 9703 43BE

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.