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

[Richard Bos]

Op Friday 12 September 2008 09:41:01 schreef Bernhard Reiter:
> Hi Richard,
>
> On Thursday 11 September 2008 17:55, Richard Bos wrote:
> >  I would
> > like to look at the samba patch that is provided in issue2997:
> > https://www.intevation.de/roundup/kolab/issue2997
> >
> > Is it okay to commit the patch to cvs?  The code must be adapted to cvs
> > and some files must be added to a Makefile that I'll take care off.  If
> > somebody finds the time to review the patch, I think that it is important
> > to look the ldap attribute definitions and perhaps the quality of the
> > code.
>
> thanks for the reminder. I am still trying to find a way to deal with
> larger proposals to extend Kolab Server (and Kolab as in Kolab Solution). I
> scanned the issue and the wiki page and what I am personally missing is an
> overview about the implications of making the change.
> This would include possible alternatives, for whom, which use cases are
> solved, why this technical approach was choosen on so on.
> Maybe we do need something like a KEP (Kolab Enhancement Proposal)
> going by the example of Python's PEPs: http://www.python.org/dev/peps/ .
> The problem is: How do we make decisions of this importance? How do we keep
> the design philosophy?

That would make things clearer from the start indeed.  Perhaps a KEP is too 
much, and perhaps it is sufficient to provide a template (or a wiki page) 
that contains the questions that you want to know.

> Any CVS person could commit, (including Richard), but none would take such
> a decison alone. Others have a hard time making up their mind, because they
> would need to take 3 hours or so out, to completely read through the
> material to be able to have a opinion on it.

I agree.  While working on issue2997 I was already afraid that someone would 
make a statement like the one above.

> For Samba, this has traditionally be orthogonal to Kolab Server and was
> integrated during project, because of the difference needs. 

I don't understand what  you want to say.  What do you mean?

> If we add 
> something to Kolab Server (and the Kolab Solution) this should cater almost
> all reasonable needs and it should not add complexity for non-samba users.

The current patch has a switch that enables or disables samba support.  For 
kolab this means that 2 functions are added and some if statements to 
determine whether samba support is enabled.  If it is enables data is written 
to the ldap database.  The current patch does not add complexity for 
non-samba users, it actually takes care that the same password can be used 
for kolab and samba (MS) logins, providing single sign on, which is a good 
thing if you ask me.  Everything else related to samba is AFAIK done with 
another GUI.

> Discussing this is not trivial and goes beyond the code itself.

You're making me curious, please elaborate.

> All, how shall we should procede? There are some obvious ideas, but they
> also mean work in one or the other way.

If I get the approval to commit the patch, I'll commit it.  But I need to get 
the approval first.  It looks like that the following questions need to be 
answered:

1) Implications of making the change (this would include possible 
alternatives)

2) For whom, which use cases are solved

3) Why this technical approach was choosen


Hopefully Albrecht wants to answers the questions.  Albrecht can you do that?

From my point of view there are the following answers:

1) Implications: the kolab team must support more code.  New ldap schemas are 
included.  No idea whether that is a problem or not.  More ldap attibutes are 
stored in ldap which could be accessed if the ACL is not correct.

2) It provides SSO (single sign on), which is very convenient for users.  
Hence making kolab even more attractive for companies :)


I hope this is a start to come to a decision about samba support in kolab.  


-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.