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

[Christian Grothoff]

On 4/8/19 3:37 PM, Schanzenbach, Martin wrote:
>> It sounds like you're suggesting that we should have a core team of
>> developers in official capacity for GNUnet e.V. to look at pull requests
>> and then say "we think that this doesn't infringe on copyright" and
>> merge them in.  Is that what you're saying?
> 
> I did not start the copyright argument and am not even sure if we need to 
> address it (see other mails).
> What I am saying is that GNUnet e.V. is currently (or better: should be) 
> vetting every contributor wrt the CAA _before_ any contribution is done.

True.

> This vetting process is not transparent and power is quite concentrated (note 
> I am not saying abused).

I'm not sure how this is not transparent, as the list of people who
signed it is maintained in the gnunet-ev.git, and the CAA is public as
well. Also, various people are in principle able to onboard new
committers. The fact that I collect the printouts is something I'm not
sure how to fix. I considered putting the signed statements into a Git,
but figured having scans of people's signatures online was a bad idea (TM).

> And a "secretary" which is the only entity able to conclude the onboarding 
> process is, by definition, an authority.

True. Nobody claimed this was perfect.

> So claiming that a restrictive fork+pull policy where members / devs sign-off 
> commits hurts the open spirit of the project is just silly.
> It is not getting any more restrictive and bureaucratic than it is now.

I fail to see how a one-time onboarding issue even relates to something
that would apply to every commit.

>> I thought we were having an interesting discussion here.  You're right,
>> nobody is forcing you to commit to master regularly.  That's fine,
>> everybody should use a workflow they're comfortable with.
> 
> 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.

Makes sense, except then Mantis has to remain. That means we have to
keep securing the installation, backing up the database, etc. For how
long? How well will this be done for a legacy system that is rarely
used? Just today I got a report on libmicrohttpd that related to a #32xx
bug which, when re-reading the ancient bug, helped me understand why the
code was written the way it was written. Loosing this memory would be a
major loss, likely more significant than loosing the commit history! So
I think some effort to try to preserve it properly is worth it. And
again, Gitlab was primarily proposed as "better CI", so if its
introduction has other costs, it makes sense to try to minimize those,
right?

> - No user forks, no pull requests -> No usability gain over gitolite

I don't recall anyone saying that. The argument was to not force pull
requests on people. And I don't think 'no user forks' was ever said (we
discussed namespaces for that, right?). Or maybe I'm not understanding.

> - 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.

Ah, but that's now a suggestion I hear for the first time. I'm not sure
what the lawyers will say about this, but if we can have scans of CAAs
collected by Gitlab (and ideally secured so that the signatures are not
out in the open), I'm all for this. That could be a process improvement,
as long as we can get it done in a way that makes the lawyers happy.

> 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.

Well, that was always my concern: that we don't _need_ much of the
functionality as we already have solutions for that. :-)

> If we use it, we need to embrace its full value offering and see it as a 
> change to improve our (CAA) processes.

That is something I could embrace, but I don't know the Gitlab
capabilities here. Can we collect a digital signature (as in, a scan?).
Can we keep those securely?

> 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...).

I think you need to have some _real_ paperwork in your life sometimes if
the single-signature CAA is "completely unreasonable".

> 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.

Many of which are optional, and often helpful to narrow down the issues.
And it serves as a long memory for the project, a history which you
propose to just erase.

> 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).

Sure, that's acceptable as well.

signature.asc
Description: OpenPGP digital signature