gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Discussion, and Help Wanted: Moving to Gitlab fo


From: Schanzenbach, Martin
Subject: Re: [GNUnet-developers] Discussion, and Help Wanted: Moving to Gitlab for Git, CI, and Issues
Date: Sun, 7 Apr 2019 11:11:51 +0200


> On 7. Apr 2019, at 11:11, Schanzenbach, Martin <address@hidden> wrote:
> 
> 
> 
>> 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.

Btw I also think it only applied to commercial platforms. So is there really a 
need to worry???

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

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]