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

[Gunnar Wrobel]

Hi Jeroen,

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

[snip]

>
> - Each component that is forcefully tied to another component (such as a
> kolab-daemon or kolab-utils component and a kolab-perl component) inherently
> also forces us to work with proper, verifiable APIs,
>
> - Proper, verifiable APIs get us to reasonable product versioning, where you
> can only bump so much at a certain time, and you are required to  
> bump the X or
> Y or Z in a X.Y.Z product versioning schema given the inclusion of  
> certain API
> changes.

[snip]

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

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.

I'm aware that "having source code alongside with the package  
definitions" was not the only point you were looking at. But I  
consider it one of the core issues that are hard to solve and make it  
hard to get to the situation you'd like to have.

In any case I agree to the points to made and if you see ways to get  
there quickly then lets start doing that. To come back to the points  
you summarized:

> - strong preference for separate repositories for Kolab components,

Very reasonable (even if the components don't have a proper API and  
are heavily linked).

Which components did you see beside the three packages I mentioned above?

> - proper product component versioning,

As mentioned we have that nearly everywhere and I actually only see it  
missing for kolab-webadmin and kolabd.

> - branching/tagging policy,

Okay with me.

> - adjacent features in the issue tracker (roadmap, milestones),

I think it is possible to do that in roundup.

> - guidelines for handling issues in tracker,

I think it is possible to do that in roundup.

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

Cheers,

Gunnar

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