[pkg-kolab] [pkg-horde] (Sort-of) forking Horde for Kolab?

[Mathieu Parent]

Hi,


On Wed, Nov 4, 2009 at 12:38 AM, Gregory Colpart <reg at evolix.fr> wrote:
> Hello,
>
> On Tue, Nov 03, 2009 at 11:08:04PM +0100, Mathieu Parent wrote:
>>
>> Currently, kolab-webclient is based on horde-webmail 1.2.0 (I don't
>> know precisely the included app versions). Upstream is 1.2.4.
>>
>> The patches for coming kolab minor version (2.2.3) are at:
>> http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/horde-webmail/1.2.0/?only_with_tag=kolab_2_2_branch
>> The patches for the next version (2.3) are at:
>> http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolab-webclient/patches/1.2.0/KOLAB/
>>
>> My initial plan was to include all non-intrusive patches in the
>> different Horde packages. But this will be intrusive anyway. To
>> clearly indentify those patches, we can put a kolab-webclient git
>> branch between upstream+patches and debian-sid.
>>
>> => Is this ok for the horde packagers?
>
> Note that "upstream+patches" branch is not really usable.
What do you mean by not really usable. Don't you use "git merge"?

> In fact, this branch should be private in order to rebase
> when new upstream release...
ok

> If you create a "kolab-webclient" branch, it's the same problem.
> How do you plan to deal with new upstream release?
> And what is the goal of the branch? Create a new package
> with duplicated source code? I hope it's not!
The goal of this branch is not to create new packages. The branches
will be linked like this (using git merge):

upstream -> upstream+repack -> upstream+patches -> kolab -> debian-sid

when a new release happen, we (as horde packagers) will push it into
upstream. then:
git checkout upstream+repack
git merge upstream
git checkout upstream+patches
git merge upstream+repack
git checkout kolab
git merge upstream+patches
git checkout debian-sid
git merge kolab

Resolving conflicts if needed. The diff.gz will be identical as "git
diff upstream+repack..debian-sid".
All the kolab specific patches (except config) will go in the kolab
branch (they also will be shown in debian-sid because of the merge)
The split of packages (app and app-config) will go in branch debian-sid.

Each change to the kolab branch will be documented in the
debian/changelog of debian-sid.

>> There is a special kind of patches which are "Config" patches. My
>> proposal for those is as follow:
>> - split all horde packages (app=imp4,kronolith2, horde3, ...) into app
>> and app-config.
>>   * app-config will contain all the /etc part and examples config.
>>   * app will depend on app-config (= ${source:Version}) | app-config-custom
>>   * app-config will conflicts with app-config-custom and recommends app
>> - the kolab-weblient package will provide app-config-custom, conflicts
>> with app-config
>> - all those packages will pass through the new queue.
>>
>> => Is this OK for horde packagers?
>
> I'm not sure to understand: what is your kolab-webclient package?
> Is it *only* for providing custom config? Seems overkill...

Upstream kolab-webclient is horde-webclient+patches (features and configs).
I see Debian's kolab-webclient as a set of conffiles and maintainers
script (to setup db, ...). See [kwc]
The feature patches will be integrated in pkg-horde-hackers's packages
like said above.

This seems unnecessary a so "tiny" package, but it is important to
allow easy installation of kolab-webclient without duplication of
code. Also the mechanism provided here can be used for other types of
preconfiguration like "Horde Groupware" [gw] or "Horde Groupware
Webmail Edition" [wm].

[kwc] http://packages.debian.org/experimental/all/kolab-webclient/filelist
[gw]: http://www.horde.org/groupware/
[wm: http://www.horde.org/webmail/

> Regards,
> --
> Gregory Colpart <reg at evolix.fr>  GnuPG:1024D/C1027A0E
> Evolix - Informatique et Logiciels Libres http://www.evolix.fr/
>