Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
[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.
> - 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.
> - allow a list of reviewed hooks to get used by users
I would call included services like email notification some sort of
hook. And everything else can run external as webhook with the added
feature that it is not longer specific to alioth.
> There is also another problem: I don't want to maintain a bigger ruby
> installation. And since I am the only active alioth maintainer left...
But you are fine with maintaining that fusionforge beast?
> However, I am not bound to this job. If there is a team that wants to
> maintain it, if DSA is happy with them, if Debian agrees that it is the way
> to go - I will happily step aside.
I'm willing to step it, as I already said last DebConf. I may not
always be in favour of the direction GitLab is heading, like the CE vs.
EE split and it gets a bit too monolitic.
But sometimes I miss some collaboration features for my Debian stuff.
Sure, I could move to github or other commercial hosting out there with
support for that, but I don't want to.
Regards,
Bastian
--
There are some things worth dying for.
-- Kirk, "Errand of Mercy", stardate 3201.7
Reply to: