Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Rich Freeman <rich0@g.o>
Subject: Re: Git braindump: 1 of N: merging & git signing
Date: Mon, 4 Jun 2012 15:27:03 -0400
On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring <ferringb@...> wrote:
> One thing people need to keep in mind here is that when you sign the
> commit, you're signing off on the history implicitly.  Directly
> addressing freeman's comment about "people sign the manifest but don't
> look at what they're signing", when it comes to git signage, bluntly,
> people doing that shouldn't have access- if they can't be arsed to
> validate what they're signing, then trusting them w/ the tree is
> probably questionable.

I suspect that you're missing my point.  The argument was made that as
long as merge commits are signed you know that unsigned commits
referenced by them are OK.  However, some of those commits might have
been already in gentoo-x86 and I doubt that anybody is going to check
those.  If I have a perfect commit, I do a git pull and a git push and
the result is a merge that references whatever was in gentoo-x86
before, whether placed there by dev, or hacker, or whatever.  Unless I
go back and review the existing gentoo-x86 history (and likely have to
repeat the process when somebody else does a push before I do), I
can't vouch for what was in there already - just what I'm adding.

The reason I mentioned maifests is that they have the same issue.  If
I keyword an arch on foo-1.4.5, I sign the manifest.  That doesn't
mean that I checked every file in the package's directory tree for
issues.  At most I checked foo-1.4.5, but I can't sign off on just
1.4.5 - I have to sign off on everything.  Also, when I sign off on
1.4.5, I'm really just signing off for the keyword change, not the
piece of buggy code I didn't write on line 37 of the ebuild.

Of course when merging a pile of commits into the tree you should
check all of them to make sure they're fine (or rather that the end
result of them is fine - no absolute need to squash together bug
introductions and fixes even if that is nicer).  However, I'm not sure
I'd extend that to checking commits ALREADY in gentoo-x86 made by some
other dev.

The general principle is that if you change something in the tree, you
should be responsible for what you changed, and that makes sense.

Rich


Replies:
Re: Git braindump: 1 of N: merging & git signing
-- Brian Harring
References:
Re: Git braindump: 1 of N: merging & git signing
-- Rich Freeman
Re: Git braindump: 1 of N: merging & git signing
-- Dirkjan Ochtman
Re: Git braindump: 1 of N: merging & git signing
-- Rich Freeman
Re: Git braindump: 1 of N: merging & git signing
-- Dirkjan Ochtman
Re: Git braindump: 1 of N: merging & git signing
-- Rich Freeman
Re: Git braindump: 1 of N: merging & git signing
-- Dirkjan Ochtman
Re: Git braindump: 1 of N: merging & git signing
-- Rich Freeman
Re: Git braindump: 1 of N: merging & git signing
-- Dirkjan Ochtman
Re: Git braindump: 1 of N: merging & git signing
-- Rich Freeman
Re: Git braindump: 1 of N: merging & git signing
-- Dirkjan Ochtman
Re: Git braindump: 1 of N: merging & git signing
-- Brian Harring
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Git braindump: 1 of N: merging & git signing
Next by thread:
Re: Git braindump: 1 of N: merging & git signing
Previous by date:
Re: Git braindump: 1 of N: merging & git signing
Next by date:
Re: [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.