Re: [gentoo-scm] Notes from a recent meeting; Updated conversion

[Robin H. Johnson]

On Tue, Oct 26, 2010 at 11:35:51AM -0500, Donnie Berkholz wrote:
> 1. http://etherpad.osuosl.org/gsoc-gentoo-dev
I don't trust the durability of this link, so I'm including the
plaintext version here.

Gentoo Developers Meeting:

Attending:
 * ramereth - Lance Albertson
 * dberkholz - Donnie Berkholz
 * robbat2 - Robin H. Johnson
 * calchan - Denis Dupeyron
 * John "warthog9" Hawley @ kernel.org
 * Shawn Pierce @ git
 * bicatali - Sebastien Fabbro
 * Corbin "MostAwesomeDude" Simpson @ OSUOSL
 * Harris Wong - Inclusive Design Institute
 * Francecsco Biscani @ European Space Agency (gentoo users...)
 * Dario Izzo @ ESA

Switching to git:
 * Talked about it for 4 years
 * People are too busy
 * Tracker bug: http://bugs.gentoo.org/show_bug.cgi?id=333531
 * Last status: http://archives.gentoo.org/gentoo-scm/msg_c0f2f8f123f85bb8b664827b4a1dcb09.xml

Main Topics: Signing Commits, Repository Layout, Other Blockers

Signed commits / verifying pusher ID
 * Preventing forgery in commits via signing commits
 * JH: overdesigning the fix
 * Mercurial has the functionality but has other issues like performance
 * Can we trust our developers? We don't trust people to keep their machines secure.
 * Want all developers to have commit access

Can we use tags for signed commits?
 * Can't revoke a tag
 * Can't remove the tags
 * Non-fast-forward merges would lose signatures
   * The commit ID changes post-merge, and it's part of the SHA1 so the sig fails on signed tags (or anything else based on `git show`)
     * If rebases are required before pushing, this should eliminate the problem

How about git notes?
 * git show | gpg foo | git note
 * What happens if someone edits the note afterwards? Hard to look through the notes
 * notes are separate
 * Using notes as a gpg-signed "signed-off-by"
 * Post-hook putting username/date in the note on the server would verify the pusher, so forgery of author/committer would not allow shifting the "blame"

Other options
 * The "update-paranoid" hook in git/contrib/ maps usernames on the server to committers
   * Unfortunately this breaks pulling from any other committers without adding them to the "verified committer" list for that user
 * The Gerrit code-review tool has repository-management controls so we could force all commits through it
 * Turning on the git reflog on the server
   * Check who's pushing, look up GECOS data and fill out committer line
   * Set reflogs to never expire
   * Could commit reflogs to a git submodule that's cloned on-demand for anyone wanting to verify
   * Unfortunately the last reflog commit couldn't be signed, but everything up to that could be
 * Developers could use signed tags for each push and upload to individual repos. Then a server process would look for tags, verify them, pull the branch, but strip the tags so the main repo doesn't clog up.


Repo layout
 * Natural option (seems to be used by most projects) is one package per repo
 * Main problems: how to manage initial clones, updates, package moves, category moves
   * The "repo" tool written for Android can handle most of this
     * Renaming packages a problem (requires admin participation)
       * Average 1-2/week over the past few years
     * Moving packages between categories can be done by committers

What the problem is:

-------------- ---> git.git
| giant .git |
--------------

In Gentoo terms, pulling one package from an overlay or other small repository (git.git) into the main repository (giant .git) is basically impossible while preserving history. This gets even more complex if you envision managing the upstream source in the same repo as the ebuild, with patches as commits (see vcs-pkg.org for discussion on best practices with DVCS).


Thin Manifests
 * Avoid conflicts with digests of every file and signatures in the Manifest
 * Already implemented for Funtoo


Preupload tracker bug #333685 - solution on the ML but needs a patch written, should be trivial
 * Basic idea: don't let people do initial clones on the repo because repacking is too demanding. Require them to externally download a git bundle for initial setup (or extremely outdated clones).
 * Checks the "I have this commit" passed at upload time
 * Existing patch to git list needs to get rewritten (ford_prefect)
   * Security concern that users on local system wouldn't trust it
   * Solution: A new config option to git-daemon supplied on the CLI that is passed on the CLI to upload-pack.


Narrow (partial-tree) clones
 * Nice but not a requirement
 * Recent patch on git list
 * Multiple per-package repos would also solve this


-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85