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: Christian Grothoff
Subject: Re: [GNUnet-developers] Discussion, and Help Wanted: Moving to Gitlab for Git, CI, and Issues
Date: Sun, 7 Apr 2019 11:02:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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.

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.

WDYT?

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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