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

Sun Nov 8 16:07:05 UTC 2009

Hi,

Quoting Mathieu Parent <math.parent at gmail.com>:

> (Gunnar, I'm cc-ing this to you as I am talking about you. Maybe you
> can give more precisions. See "why it could not be accepted
> upstream?")
>
> Hello,
>
>
> On Sun, Nov 8, 2009 at 2:06 AM, Gregory Colpart <reg at evolix.fr> wrote:
>> Hello,
>>
>> On Thu, Nov 05, 2009 at 09:29:16PM +0100, Mathieu Parent wrote:
>>> >
>>> > Note that "upstream+patches" branch is not really usable.
>>> What do you mean by not really usable. Don't you use "git merge"?
>>
>> No. "upstream+patches" branch is here for git-format-patch in
>> debian/rules to generate debian/patches/.*
>
> OK.
>
> I hope that my misunderstanding has not created incorrect packages, as
> I have merged as said.
>
> For example:  
> http://git.debian.org/?p=pkg-horde/turba2.git;a=commitdiff;h=f6d45a34458d783052b3195e6d42a70df959cb0e
>
>
>>> > 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
>>
>> As I said above, workflow is not exactly like you describe:
>> "upstream+patches" branch is not merged in "debian-sid".
>> But it's not an essential point.
>
> Yes, those patches can be included in the upstream+patches (u+p)
> branch or in a kolab branch merged in u+p.
>
>
>>
>>> 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.
>>
>> Ok. Then you want push kolab specific patches to horde3 source
>> packages. I prefer to keep only one "patches" branch.
> ok
>
>> My question is : if patches could be in horde3 Debian package,
>> why it could not be accepted upstream?
>
> The process of integrating those patches is ongoing. Gunnar Wrobel
> (who is also the gentoo packager for kolab) is pushing those patches
> and an amazing job has already been made. See
> http://github.com/wrobel/horde-release/blob/t/KOLAB/STATUS
>
> The remaining patches have not been accepted for various reasons, mainly:
> - not submitted yet (Gunnar want to clean them a bit, or they are too new)
> - rejected because they don't respect horde coding guidelines and
> should be implemented in a better but more intrusive way.
>
> Gunnar is currently working on implementing those patches (and others)
> in upstream Horde4.
>
> The remaining patches are not critical ones, so kolab-webclient will
> be functionnal without (and also some of them are already integrated
> as kolab usptream uses horde-webclient 1.2.0 instead of 1.2.4)

My intention is to keep the patch queue as small as somehow possible.  
And as the Horde team is currently busy working on Horde4 it is a good  
time to get rid of some patches by integrating them upstream.

However I would not expect the patch queue to be eliminated  
completely. The customers of the Kolab Server desire new features from  
time to time that are not easy to directly integrate into Horde  
upstream. Sometimes that works but sometime we wouldn't be able to  
offer a feature for a reasonable price if we are as pure as Horde :)  
These patches just take longer (and longer often means years).

The best solution from the viewpoint of a distribution is to offer a  
certain flavor of the package. It should of course not be a full  
replicate of the original package as that would mean we are doing a  
real fork (which we are not). But the user should be able to choose  
the flavor of the package when he install it. In Gentoo speak: He  
activates the "kolab" use flag for the horde-webmail package.

Cheers,

Gunner

>
>>> >> 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
>>
>> I'm very not convinced this is the solution to allow easy
>> installation. .sql files could go to classic packages. And
>> conf.php files are conffiles generated by Horde webadmin, and
>> I think we could find ideas to have an easiest installation (if
>> really needed) without creating dozen of new binary packages...
> I agree. So tiny packages is not good.
>
> While reading http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.4
> (Sharing configuration files), i thought about using alternatives.
>
> horde3 will provide an alternative: "horde-config" defaulting to
> /etc/horde/horde3 and /usr/share/horde/config will point to this
> alternative.
> Same for imp4, turba2, kronolith2, ... (all horde packages)
>
> horde3 will also provide another alternatives for horde-config,
> imp-config, ... with smaller priority that will point to
> /etc/kolab-client/appN.
>
> With this solution, no new package is needed as the kolab-webclient
> configs are included in horde3.
>
> Summary:
> - use alternatives for appN-config, defaulting to /etc/horde/appN
> provided by package appN (no new package needed)
> - horde3 provides  also /etc/kolab-webclient/appN directories (foreach
> appN), with a lower alternative priority for appN-config (files
> maintained by pkg-kolab members)
> - include kolab patches in Debian Horde packages one by one (as
> needed) in upstream+patches branches
>
> Gregory, does this sounds better to you ? Does this sounds good enough ;) ?
>
>> Regards,
>> --
>> Gregory Colpart <reg at evolix.fr>  GnuPG:1024D/C1027A0E
>> Evolix - Informatique et Logiciels Libres http://www.evolix.fr/
>>
>
>
> Mathieu Parent
>

-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------