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

[Christoph Wickert]

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

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

I guess Horde 4 should not just sit on top of a Kolab server that uses Horde 3 
code. You invested a lot of work to clean up the code duplication in the 
server and the webclient and I guess you did not do it just to bring it back 
later with two different Horde versions. So where should this development 
effort take place - if not in it's own branch?

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.

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

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20110915/b64f52cd/attachment.sig>