On Wed, 08 Jun 2016, Pirate Praveen wrote: > On Wednesday 08 June 2016 01:07 AM, Bastian Blank wrote: > > [SN: trimmed Cc list, as this is about what Debian wants] > > > > Hi Alex > > > > On Tue, Jun 07, 2016 at 08:06:41PM +0200, Alexander Wirt wrote: > >> Its more things like: > >> - integration into alioth - aka, how easy is it to integrate the already > >> existing identity data (which we want to keep) into the system > > > > This can be easy (use OAUTH2 against the identity provider) or hard > > (convert all data). Also it speaks ldap itself. > > Does alioth/fusionforge already support becoming an OAUTH2 identity > provider? How do other debian services (like nm.debian.org) use alioth > login? [1] I found this [2] I wrote a minimal exporter for user information (no group or acl information) that gets synced to the dacs host. That enables dacs enabled services to use these information. Please keep in mind that dacs is not available for non dsa enabled hosts. > >> - mapping groups and permissions from alioth to the new system > > > > Fusionforge also uses a similar group based permission system. > > > > Okay, there is this (hacked in?) "allow every DD to write" permission > > that some groups use, which is only supported by gitlab EE. Alioth uses some role based model where specific permissions get mapped to (pre-)defined roles. We will never be able to get that into a different system et al. My current plans are limited to group information and admin flags. Everything else will need to get redefined by the admins to the specific system. > > We'll have to ask gitlab folks if they are willing to provide that in CE. I am also not very keen on using a system with a "open core / enterprise" model. For such a crucial service I would really prefer a real open source system. But maybe I am alone with that oppinion. Alex
Attachment:
signature.asc
Description: PGP signature