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

[ng0]

Christian Grothoff transcribed 8.1K bytes:
> 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.

I had to ask where this list is. So I have this 1/4 finished document
which is not a good on-boarding document, but a better one than now,
which is nix, nada. So we should mention little details like this on
the website or in this guide.

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

I remember having to sign a similar document for Erlang contributions,
but they abstracted it into their github-centric organization, so
to have it only digital should be doable if Erlang gets away with it
(also a european business, located in Sweden). 
 
> > 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.
> 




> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

signature.asc
Description: PGP signature