Re: [GNUnet-developers] Discussion, and Help Wanted: Moving to Gitlab for Git, CI, and Issues

[Florian Dold]

> No, we don't. We dvn et al are faced with unreasonable requirements for the 
> use of gitlab which include:
> 
> - Migration of Mantis issues -> completely unnecessary. Mantis could remain 
> read-only for the "legacy" issues and gitlab used for new issues.
> - No user forks, no pull requests -> No usability gain over gitolite
> - No automatic user onboarding  > The CAA could be included in a pull request 
> to the main repo btw. In combination with signed requests this would suffice. 
> Also, forks are not touched by the CAA while a push into the main repo is. So 
> the entry barrier is much much higher for initial contributors.

Okay so let's first clear up an apparent misunderstanding.  I am not
advocating for these restrictions.

In fact I think that pull requests on GitLab are a *great* workflow for
completely new or infrequent contributors.  In fact, there are some more
complex changes where I'd be happy to use a pull request and get some
feedback first.  But I don't want to create a pull request for fixing
some typo in a comment somewhere.

But for somebody who's through the CAA bureaucracy, I don't see why we
should *require* every change to go through a manual pull request with
1-2 sign-offs.  They can just push to master, with some automated checks
in place.  GitLab doesn't prevent this in any way.  It doesn't prevent
whoever wants to do a pull request to submit one.

(For mantis, let's try to have a best-effort migration at least.  I also
think that user sign-ups should be approved by someone from some admin
group, otherwise this is ripe for abuse, some anonymous people will just
use gitlab.gnunet.org as their file hosting service otherwise.)

> All in all I fear this project is a really good idea but doomed from the 
> start.
> Using gitlab only because of its CI will just not be good enough and just 
> adds another (quite large) tool where the most of the useful functionality is 
> unused.
> If we use it, we need to embrace its full value offering and see it as a 
> change to improve our (CAA) processes.
> 
> To me, this has practical impact:
> I regularly have students which work on projects wrt GNUnet.
> While I would like them to work on it directly, this is completely 
> unreasonable because of the CAA and the fact that GNUnet tooling is not good 
> (I am trying not to use strong words here...).
> There is _no_ gain from using the GNUnet repos and services. On the contrary!
> No CI, no issue integration into commits, a single repo littered with 
> branches. An issue tracker from the 90's with a gazillion entries to fill in.
> Hence, I usually tell them to fork it and work in private on it on a gitlab 
> instance.
> After the work is done (and successful) I may convince them to merge the code 
> (and sign the CAA).

Yes, I get it.  Thanks for writing these down in detail.

I'm definitely willing to give up some of my "admin conveniences" that
gitolite provides to make the developer experience better.  I have some
technical objections to GitLab vs. gitolite, but I can live with them.

- Florian

signature.asc
Description: OpenPGP digital signature