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 > GNUnet-developers@gnu.org > https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: PGP signature
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers