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

[Schanzenbach, Martin]

> On 7. Apr 2019, at 11:02, Christian Grothoff <address@hidden> wrote:
> 
> On 4/7/19 8:33 AM, Schanzenbach, Martin wrote:
>> Contributors should be able to do anything they want in their own
>> namespaces including committing code that does not compile (e.g. for
>> their gnunet.git forks). However, in order to get it into the "main"
>> gnunet project codebase, the CI must pass for the respective pull
>> request and I would argue that 1-2 "main" devs should sign off on the
>> commit (this allows us to control the CAA issue a bit).
> Eh, sorry, but under forthcoming EU regulation, we cannot even host
> contributor's code without having a signed the CAA. So Git pushes should
> only be possible for people that signed the CAA, and in that case if a
> CAA-signing contributor has pushed a change to a namespace/branch that
> by convention is to be merged, we should ideally automate the merge.

I think you misunderstand the new regulation. Having a CAA does not protect the 
platform from this.
It is not enough to have the user state that the code is his, the platform must 
verify/ensure that.
No legal document is able to absolve us from this.

> 
> However, given that we cannot then preserve the gpg signature on the
> commit (depending on how the merge goes), maybe indeed we _need_ a dev
> to do the sign-off just to get at least one proper gpg signature on the
> commit.  In that case, maybe the CI can automatically send an e-mail to
> a group of devs that are on sanity-checking + gpg-signing duty.
> 
> Anyway, the CAA issue should be solved prior to any Git write access,
> and the sign off step _may_ be (borderline) acceptable to address the
> GPG signing issue, but it shouldn't be seen or phrased as that this is
> done by the "main" devs. The sign-off should be more more like a
> secretary position for pushing the paperwork along.

Well then the whole "open participation" thing is moot anyway and I wonder why 
it comes up all the time here.
If we have a beaurocractic onboarding process including the CAA (which we do 
not have atm btw), then participation is limited and must be done through 
gatekeepers anyway.
OTOH, I do not really see a problem with fork+edit without the CAA. The problem 
_only_ arises when the code is merged into the main repo.
Which is why I think my proposal is better. (apart from the EU regulation 
stuff, but there is no solution to that)

> 
> WDYT?
>

signature.asc
Description: Message signed with OpenPGP