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

I noted on my task list to document what I consider the current policy  
concerning upstream packages is. I think this is indeed currently  
missing and only visible by looking in the Makefile in CVS. So this  
should appear on a wiki page soon. And we could continue from there.  
Does that sound reasonable?

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.