From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SbWWX-0004aF-Uj for garchives@archives.gentoo.org; Mon, 04 Jun 2012 12:36:42 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 00487E073C; Mon, 4 Jun 2012 12:36:21 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 7C6BEE05B1 for ; Mon, 4 Jun 2012 12:34:31 +0000 (UTC) Received: by bkcjk13 with SMTP id jk13so4026279bkc.40 for ; Mon, 04 Jun 2012 05:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=M5MFHCHPFM0J8L/k3qNUtLVAysmHw5Aw2Rvx/VaY3w4=; b=PKkFlXkHq6Yu55zdMG/VnEo1E4UxIvH71nBedUxyM9tZJ8CwsL/QRXXFuKYQZsgCqo RTBArjOu+koRi0gcuqsDoRxDT+t0ZYKKZIGraYCrs+GwWtHiLHnCyeGWxHdf8oFt4sng 52Wr+g9y+YCl1HgWxRpEdm6LYoucTpG/6Tn14OTKAgpjQKcq6UnjefV/dTf2SRS5qjOY rOpGoN4TXIM+IZ9g91zfm8O8uVX0PKt5BLwG9FtPBlYt6YAg/JDXZIoUvkJInetqqmNP q6PbDLNr8Uiwe0la4xS21jNFxm/xY4WmUWjjWa94c5S0pocTS59rmPOYfC0NeneGApVT JulQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.130.85 with SMTP id r21mr6825830bks.53.1338813270423; Mon, 04 Jun 2012 05:34:30 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.204.149.211 with HTTP; Mon, 4 Jun 2012 05:34:30 -0700 (PDT) In-Reply-To: References: <201206031239.21744.dilfridge@gentoo.org> <201206032135.49757.dilfridge@gentoo.org> Date: Mon, 4 Jun 2012 08:34:30 -0400 X-Google-Sender-Auth: skTAqHg1qCflXAIpeZUJmxv5V1w Message-ID: Subject: Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: dedfc191-3265-4496-81bf-3499312d967d X-Archives-Hash: a09e12c0e036beb005843749ffeb3231 On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman wrote: > On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel = wrote: >> However, then the "committer" of the contributed commits before the merg= e is >> then the user, I guess? >> >> (The rule meaning as suggested by Robin >>> - if you include a commit from a user: >>> =A0 author :=3D non-@gentoo >>> =A0 committer :=3D @gentoo >>> =A0 signer :=3D $committer > > I guess, I'm not sure how the committer thing works in git. > Well, only Robin can explain exactly what he meant, but it sounds like we don't want the committer field to ever have a non-gentoo email in it, and signatures should be gentoo as well. So, if a dev just applies a patch to their tree/etc then there is no issue (just set author). If a dev wants to actually pull in a commit they'd need to edit the fields accordingly and re-sign it. Not sure offhand how to best do that (I assume it is possible - probably with some variation on rebase or something rebase calls). I don't think the intent is to snub non-devs. The issue is what is the purpose of the signatures and committers field in the first place. The signature verifies that the commit is intact, and you can only do that if you have a key to check it with, and you can trust that key. If the signer is a dev then we already have policy that the keys need to be published, and we have a list of key IDs on our website. I'm sure that could be improved on. If we stick non-dev signatures in the tree then that becomes more of a problem (though it clearly is possible - maybe something to think about). I assume the committer denotes a layer of accountability, and having a dev in that spot makes sense (devs who are proxies are accountable for oversight at some level - though I'd personally give them the benefit of the doubt since we want to encourage the proxy role). I think the key with git is to not let the perfect be the enemy of the good. We don't have an unbroken signature chain on our current portage tree, so I don't think we need one to move to git. As long as git is at least as good as what we have now, then we should accept it. We should of course strive to improve, but let's not keep the almost completely unsigned cvs around for another 10 years while we argue about signatures. Rich