> 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
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
