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

[Schanzenbach, Martin]

> On 7. Apr 2019, at 19:20, Florian Dold <address@hidden> wrote:
> 
> On 4/7/19 6:46 PM, Schanzenbach, Martin wrote:
>> The CAA does not help in any way. You are still liable as a platform. It has 
>> literally nothing to do with the copyright infringements if the contributor 
>> copied code from somewhere else. You cannot delegate this responsibility 
>> anymore to the user. That way the old way of doing it.
> 
> I am not sure what requirements you are talking about.  Do you have some
> reference that explains this?  Christian, do you have one?  I would
> guess we are probably not the only project affected by this.
> 
> 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.
This vetting process is not transparent and power is quite concentrated (note I 
am not saying abused).
And a "secretary" which is the only entity able to conclude the onboarding 
process is, by definition, an authority.
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.

> 
> If somebody hosts code on the GNUnet gitlab that infringes copyright,
> wouldn't we also be responsible for this?  How does the pull request
> policy solve that?
> 
>> Just do whatever you want. I think I will stop bringing myself in this 
>> regard and just develop in an external mirror repo occasionally rebasing my 
>> stuff in the main repo. This way, you can even keep gitolite -> win win
> 
> 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.
- 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.

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

> 
> - Florian
>

signature.asc
Description: Message signed with OpenPGP