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

[Gunnar Wrobel]

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>:
>> > kolabd/kolabd.spec |    6 +++---
>> >
>> >  release-notes.txt  |   12 ------------
>> >  2 files changed, 3 insertions(+), 15 deletions(-)
>> >
>> > New commits:
>> > commit 0e8e44b895887ae349f3db9dadb3af36e390670c
>> > Author: Christoph Wickert <wickert at kolabsys.com>
>> > Date:   Tue Sep 13 19:04:15 2011 +0200
>> >
>> >     Revert "Require the PHP filter module."
>> >
>> >     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.

This is what irritated me. I fully understand that there was a certain  
pressure to get 2.3.3 out the door.

Under normal circumstances I have no problems with getting my commits  
reverted and discussing the technical aspects. But in this case you  
took the solitary decision that this can at least wait until the next  
release without trying to contact me again. Working together with  
Thomas and the Kolab server dev community in the past years I came to  
expect something different. I probably wouldn't have had the time to  
react - but the impression would have been quite different if I had  
seen any type of ping ten minutes before reverting.

Do I ask for too much if I expect the small curtosy of a short ping  
*before* reverting a commit if the release is imminent?

Regards,

Gunnar

>
> Let me explain my decision:
>
> 1. Changes for Horde 4 have nothing to do in '2.3-stable'. 2.3-stable is a
> branch for bugfixing *only*. That's why you have your own 'horde4' branch.
>
> 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.
>
> Please note that I did not revert the changes in php and apache-php, so you
> can easily enable the filter module at any time.
>
> 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