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

[Bernhard Reiter]

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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20080917/73195f18/attachment.sig>