[Kolab-devel] Samba KEP (Re: Enhancing Kolab decision making (re: Is it okay to commit the samba patch to cvs?))

Gunnar Wrobel wrobel at pardus.de
Fri Sep 19 14:05:17 CEST 2008


Quoting Bernhard Reiter <bernhard at intevation.de>:

> On Monday 15 September 2008 17:19, Gunnar Wrobel wrote:
>> > The next point is one of the target group for Kolab Server users.
>> > Any IT solution, just like Kolab or a competitor will not conquer the
>> > market in one go. It better to first target specific markets.
>> > So the question is: Will adding a feature (like Samba) help us to conquer
>> > the next market we would want to go for with Kolab and its Server?
>> > Samba integration seems to be possible so the problem is not keeping
>> > anybody from "buying" Kolab Server.
>>
>> This sounds a little bit as if the suggested KEP process does not   
>> distinguish between a structural enhancement and an extension. I  
>> see  that as an important difference.
>
> A good remark!
>
>> If a KEP could suggest enhancing the Kolab Server with a specific   
>> application as an addon (e.g. the Open Ticket Request System (OTRS)  
>> or  Munin as a monitoring tool) then the Kolab Konsortium would  
>> always  have to ask: Does this have significant market value? Do we  
>> really  want to add it? For any additional application additional  
>> testing is  required.
>>
>> But adding such extensions to the Kolab Server is already possible   
>> today. An experienced user could build OpenPKG extension packages   
>> (even if nobody does it yet and I consider this still way too   
>> complicated - but that is not the point here). So for such  
>> extensions  I don't see the need for a KEP process as anybody could  
>> build and  distribute packages without additional overhead.
>
> Still there is the decision whether this should come with the default
> Kolab Server/OpenPKG distribution ...
> One value of Kolab Server has been its integrated testing.
> (This has been relaxed a bit with the Webklient now being in Beta,
> but still part of the Kolab Server/OpenPKG release.)
>
> The idea to have add-ons with a different support or maturity levels
> still is a good one, but of course we are lacking structure, concept
> and all this for it right now.
>
>> But I consider KEPs relevant once we talk about structural changes  
>> to  the core Kolab Server in order to *enable* specific additional   
>> extensions. This is of course the case for Samba. This is in fact a  
>>  very good example of that. Adding this functionality won't be  
>> possible  without some general hooks in the server that allow such  
>> an extension.
>>
>> Do people agree that we should keep the focus for KEPs like this?
>
> The question of inclusion in the core distribution needs to be a KEP as well.

But wouldn't this be a completely different decision process?

Lets say somebody would propose to restructure the kolab-webadmin or  
add minor features to kolabconf and we'd discuss this via a KEP. Then  
this can easily be a community process. But inclusion of complete  
applications is a different thing in my eyes. Complete applications  
have completely different needs concerning the testing. You already  
mentioned that this has (or is) a problem with the Kolab Server web  
client which did not get the testing to make it rock solid in the  
current server version.

Would a decision on such a KEP also be a community process? The  
testing would still be done by KK.

I believe we should just try to be more open to such extensions and  
provide some upload place or some other structures instead of going  
all KEPpy on extensions that provide new applications.

Cheers,

Gunnar

> A proposal is needed if the effects of a decision is potentially large.
> Creating extensions in a certain way can have such a large effect,
> even when it is decided to not to pick them up for distribution as Kolab
> development community.
>
> I agree that a KEP should clearly state what its goal is of course! :)
>
> Best,
> Bernhard
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



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


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the devel mailing list