[Kolab-devel] Branch '2.3-stable' - 2 commits - kolabd/kolabd.spec release-notes.txt

[Gunnar Wrobel]

Quoting Christoph Wickert <wickert at kolabsys.com>:

> On Thursday 15 September 2011 05:56:54 Gunnar Wrobel wrote:
>> Quoting Christoph Wickert <wickert at kolabsys.com>:
>> > On Wednesday 14 September 2011 10:21:51 Gunnar Wrobel wrote:
>> >> Quoting Christoph Wickert <wickert at kolabsys.com>:
>> >> >
>> >> >     This reverts commit a59de23c20253f613ac55edc4293798f96f8928d
>> >> >     because it should never have happened in 2.3-stable but in the
>> >> >     'horde4' branch.
>> >>
>> >> *Absolutely not*.
>> >
>> > Why not? What is the rationale to have this in 2.3-stable?
>> >
>> >> Why has this been reverted without further communication?
>> >
>> > There was no time for communication, I am releasing 2.3.3.
>>
>> > Let me explain my decision:
>> Took the discussion of the technical aspects to another mail.
>
> Maybe I missed a mail, but so far I have not seen much technical discussion.
> You have not yet explained why these commits should go into *2.3-stable*.

Because it would have saved users some hassle when installing Horde 4  
via PEAR on the Kolab server.

>
>> > 1. Changes for Horde 4 have nothing to do in '2.3-stable'. 2.3-stable is
>> > a branch for bugfixing *only*.
>>
>> We had internal communications on the PHP filter module before I did
>> the commit and I believe I made my intention on commiting this to
>> 2.3-stable clear. So I wonder a bit why you mention this only now.
>
> It is true that we spoke about this but I told you to only do it if you have
> free time. If you told me that you want to make a useless update in  
> the stable
> branch, I would have clearly objected.
>
>> > That's why you have your own 'horde4' branch.
>>
>> "horde4" is a stale branch and I deleted it in order to clarify this.
>
> So where should the Horde 4 development take place?

On git.horde.org. If there will be an additional effort of getting an  
OpenPKG specific port Horde 4 then you will decide where this will  
happen.

>
> I guess Horde 4 should not just sit on top of a Kolab server that  
> uses Horde 3
> code.

No, not really. The recommended way is (and has been) to install Horde  
on a separate machine. The preferred method of doing that is by using  
Suse packages, Debian packages, Fedora packages or PEAR. Of the ones I  
name here PEAR and Suse are already available, Debian is in progress.  
I did explore the option of providing OpenPKG packages for the Kolab  
server but taking into account that OpenPKG support is likely going to  
be dropped rather sooner than later I did not push this any further.  
This is something that makes only sense when doing it together with  
Kolab Systems. But it would mean switching the whole Kolab Server over  
to Horde 4. This does not seem to be on the horizon at the moment but  
I'm of course happy to hear the opposite.

That being said: I consider it a valid option for the users to install  
Horde 4 via PEAR on the Kolab server.

> You invested a lot of work to clean up the code duplication in the
> server

You know that I was never a complete fan of removing the code  
duplication. I see the advantages but we both also experience the  
drawbacks of having moved away from the release mode upstream (Horde  
3) provided. But I guess that is beside the point here.

> and the webclient and I guess you did not do it just to bring it back
> later with two different Horde versions.

It is one thing to have several variants of the same major version in  
you system and another to have different major versions installed in  
your system. I'm used to having distributions doing that for several  
libraries.

I can't change the fact that Horde 4 as a Kolab client will be  
available sooner than we will be able to switch the Kolab server to  
Horde 4. At some point you personally mentioned that you would like to  
avoid that switch. If that would be the case and I would consider it a  
blocker to have two major versions of Horde on the same system then  
this would mean the users never have access to it.

Of course I wouldn't mind moving the whole server over to Horde 4. But  
that is something I can only do together with you and I'm of course  
happy if you tell me that we can move into that direction.

> So where should this development
> effort take place - if not in it's own branch?

You tell me.

>
> I think this is a good time to outline your plans for Horde 4. This will not
> only help me and the other developers but also the community because the only
> info we have on this topic is outdated.

Did the above clarify it?

>
>> > 2. As there were no functional changes in kolabd there is no reason for
>> > an update, we just continue with kolabd 2.3.2 instead of forcing our
>> > users to download and update more than required. Now that I am to
>> > release 2.3.3, this means I tag 2.3.3 in git. The tag *MUST* match with
>> > what we ship and thus I *had* to revert your changes.

Absolutely and without a question. I was not asking you to avoid  
reverting it, I was asking for a ping that I would have considered  
polite.

>> >
>> > 3. Changing kolabd to force building the php filter module was the wrong
>> > approach. kolabd does not need the module but Horde 4 does. Therefor your
>> > Horde 4 packages should require it, not kolabd.

Absolutely correct. The only problem: It has never been done that way.  
Take a look at the current dependencies in kolabd: Why are all the php  
modules in there? Are they required? We both know the package is not  
clean and never has been.

>> >
>> > 4. If you had done this change in the Makefile of php and apache-php or
>> > in install-kolab.sh, it would have been in 2.3.3 without any changes
>> > because both
>> > got updated. Your change would have just slipped in without any hassle
>> > for me or our users, but the way you choose was not acceptable.
>>
>> I guess we don't need to discuss the points you raised above if you
>> say you are willing to accept the change in this way.
>
> Actually I'd like to discuss these points, at least I'd like to know if you
> can understand my POV or not.

As mentioned before: Absolutely. The technical aspects were no  
question. But I didn't perceive the problems before. You did and that  
is why I asked to be contacted.

>
>> I would simply
>> flip the "with_filter" default to "yes" if that is okay for you.
>
> You mean in the specs? All options should be turned of by default  
> and required
> ones should be enabled in the Makefile and (if still necessary) in install-
> kolab.sh.

So I obviously didn't get that point. What is required to get the change in?

Cheers,

Gunnar

>
> Regards,
> Christoph
>
> --
> Christoph Wickert
> Senior Engineer
>
> Kolab Systems AG
> Zürich, Switzerland
>
> e: wickert at kolabsys.com
> t: +49 251 871 369 77
> w: http://kolabsys.com
>
> pgp: 85DACC63 Christoph Wickert

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de