[Kolab-devel] Some patches

[Jeroen van Meeuwen (Kolab Systems)]

On 2011-11-21 19:58, Mathieu Parent wrote:
> 2011/11/21 Jeroen van Meeuwen (Kolab Systems) 
> <vanmeeuwen at kolabsys.com>:
>> Hi Mathieu,
>
> Hi Jeroen,
>
>>> Can someone allow me to push to the new git repositories?
>>>
>>
>> I think I've made it so you now have access - it wasn't really a
>> permission problem, but not having made those repositories available
>> through Gitosis.
>>
> I still can't pull and/or push:
>
> kolab-conf, kolab-server, kasync, keps, kolab-conf, kolab-docs,
> kolab.org-www, kolab-schema, libkolabxml, pykolab
> ERROR:gitosis.serve.main:Repository read access denied
> -> fetch and push failed
>

These are not amongst the ones I had opened up. For most of these, a 
lot of new information would need to be disclosed prior to enabling 
community to participate in its developments.

That said, for read access, you're better off using the git:// URLs.

That said:

> kolab-conf,

Converted split repository from the traditional kolab-server 
repository. Not finalized.

> kolab-server,

Converted split repository from the traditional kolab-server 
repository. Not finalized.

> kasync,

Kolab ActiveSync configuration for Horde.

> keps,

Read access is public, not through gitosis, restricted to existing KEP 
Authors and Secretariat as far as write access is concerned.

> kolab-conf,

Duplicate.

> kolab-docs,

Tremendous load of documentation -work in progress-, to which 
'git-kolab.org-server' has commit access, but not through gitosis.

> kolab.org-www,

Ongoing effort to revamp our web-presence.

> kolab-schema,

Converted, split and stripped down version of the basic schema 
extensions required by a Kolab deployment (i.e. not including 
kolabGermanBankArrangement).

Needed for customer deployments, unreleased as of yet, and subject to 
definition and acceptance of a variety of KEPs I currently have in draft 
status;

http://wiki.kolab.org/User:Kanarip/Draft:Definitions_of_Kolab_Objects
http://wiki.kolab.org/User:Kanarip/Draft:Kolab_Account_Types
http://wiki.kolab.org/User:Kanarip/Draft:Kolab_LDAP_Schema_Extensions
http://wiki.kolab.org/User:Kanarip/Draft:Use_of_LDAP_Bind_Credentials

as well as:

http://wiki.kolab.org/User:Bruederli/Draft:Kolab_Webadmin_API

> libkolabxml

GIT repository for the not-set-in-stone-yet Format changes lined up for 
inclusion with Kolab 3.0, in its experimental stages, not even yet 
having brought a KEP draft to conclusion, noted that no 
development/release process for Kolab 3.0 has been opened up for 
participation yet, either.

> pykolab

My craftsman-ship of sorts. Multi-domain, multi-authn/authz database, 
multi-threaded, multi-foo, plugin-enabled, kolab stuff.

> kolab-webadmin, perl-Kolab:

Neither are likely to survive a Kolab 3.0 development cycle from where 
I am sitting. That said, it would thus be maintenance-only for 2.3, for 
which we can't/don't split up the repositories because it would break 
OpenPKG build processes, and we can't negate OpenPKG as the primary 
release mechanism for the 2.3 series.

> error: insufficient permission for adding an object to repository
> database ./objects
> -> push failed (fetch OK)
>

git-kolab.org-server group permissions had not been fully propagated 
down the filesystem tree; it was stuck on git-kolab-cvs group 
permissions. Sorry about that, it should be fixed by now.

> As a side note, consider using gitolite instead of gitosis. I allow
> permissions per branch you can forbid forced push.

gitolite doesn't serve some of our infrastructural / functional 
requirements I'm afraid, one of which is to allow the use of POSIX 
permissions from LDAP to be applied to the repository as well, outside 
of a separate list of repositories and groups and members of these 
groups to need to be configured. I'm very strongly in favor of ditching 
gitolite, but not to replace it by gitosis. I don't like the commit 
messages coming from the git service user, I don't like the 
administration of it all, and I have provided a git at git.kolab.org:<repo> 
interface purely to avoid another discussion as it was put forth as a 
request/requirement in order for us to be able to move to GIT.

I myself would rather have stuffed everyone in LDAP and made the wiki, 
bugzilla and other web-interfaces and applications authenticate and 
authorize all of you against the same user database.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08