[Alioth-staff-replacement] Alioth needs your help

[Philip Hands]

Alexander Wirt <formorer at formorer.de> writes:

> On Sun, 20 Aug 2017, Philip Hands wrote:
>
>> Michael Lustfield <michael at lustfield.net> writes:
>> 
>> > On Sat, 19 Aug 2017 10:02:15 +0200
>> > Geert Stappers <stappers at stappers.nl> wrote:
>> >> On Fri, Aug 18, 2017 at 04:00:23PM -0700, Michael Lustfield wrote:
>> >> > On Fri, 18 Aug 2017 23:24:35 +0200 Philip Hands <phil at hands.com> wrote:  
>> >> > > > One thing that was said during discussion, is that if someone wants to
>> >> > > > maintain an alternative as <my-prefered-solution>.debian.net it is
>> >> > [...]
>> >> > I'll send an update when I have something exciting to share! :)  
>> >
>> > http://gitea.debian.net is live.
>> >
>> > It's running the latest gitea revision, which means bugs are likely. I built
>> > this with budget VPS instances so it's entirely possible it could run into OOM
>> > problems. If anyone notices them before I do, please let me know so I can add
>> > some resources!
>> >
>> > There's a config cheat sheet if anyone wants to suggest I change something:
>> >   https://docs.gitea.io/en-us/config-cheat-sheet/
>> 
>> One thing that came up with the gitlab setup is the creation of users,
>> and differentiating DDs from guests somehow.  In Alioth we append -guest
>> to non-DD accounts, to avoid polluting the namespace.
>> 
>> With gitlab, it's currently not obvious how to make that happen, so it
>> seems we'll need a bespoke front-end for allowing things like guest
>> registration, and will then need to stop people from changing their
>> account names from within gitlab.
>> 
>> It occurs to me that we could make that front end such that it can
>> register users in multiple git platforms, so that when they register
>> they get the same account created in gitlab, gitea, and whatever else
>> anyone sets up, so that we don't get any clashes between the
>> alternatives.
>> 
>> An alternative way of doing it would be for the registration process to
>> check with all other platforms to see whether the account already
>> exists, and if so that the associated email matches, in order to ensure
>> that it can only be created if it is either a new account, or an
>> existing account belonging to the same person.
>> 
>> Perhaps you can have a ponder about how to best achieve this from the
>> gitea point of view.
>> 
>> Another thing to consider:  The fact that groups share the same
>> namespace (in gitlab at least, and presumably all of these things, since
>> they're inspired by github, which does likewise).
> tbh, I think it is a completly waste of time to setup another git implementation at the
> current point.

It seems to me that we have people that are enthusiastic about setting
up alternative git implementations at this point.  If they feel that
they have time to spend on that, I doubt that time is wasted.

If you tell them not to do that, I seriously doubt that they'll respond
by volunteering to help with gitlab, because their enthusiasm lies
elsewhere.

However, if you let them get on with it, either they will prove to
themselves (and probably everyone else) that their preference is good
enough to keep it running in the long term (which doesn't seem like a
bad thing), or they'll realise that gitlab is better and give up.

Are you concerned that having alternatives will drain resources from
the gitlab effort?  I don't really see why that has to be the case.

If things like the registration process are designed to be agnostic of
the underlying platform, that seems like a good thing too.  In light of
Luca's recent mail, it seems like there might be the option of just
letting DSA handle user management, which would presumably make things
easier on the gitlab side of things.

I also think that having more than one git implementation for Debian is
quite a good thing.  If nothing else, it might serve to remind people
that git is not actually a centralised service.

It will also provide resilience, since people could set up their repo on
one platform according to their preferences, with another platform
acting as a pushed slave.  If there's a problem with the first, just
redefine which is the canonical repository, and they can be up and
running again in moments, with the effort being done by the repo's
owners, rather than the only option being to wait for the salsa.d.o
admins to restore backups (if that's the only platform in use).

It is of course possible that gitlab is the best possible option, and
all others will fail for one reason or another, but even that is a good
outcome IMO, since it will silence any critics who think that we should
have chosen differently, and might even recruit some of the supporters
of other platforms to helping out with gitlab, having tried and failed
with their first preference.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/alioth-staff-replacement/attachments/20170820/b83dc80c/attachment.sig>