procedure for migrating to git, patch ingress policy, actual main issue

Andy Green andy at openmoko.com
Tue Mar 11 09:56:48 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

> - for now, change nothing, i.e., we keep SVN+quilt and git in parallel
> 
> - once we're good for MP, I'll take a few weeks off. Matt has
>   volunteered to act as caretaker for the SVN+quilt repository during
>   my absence. (Thanks, Matt !)

You seem to have elided a bit from how we left it in .tw, which involved
explicit migration to git during your holiday and someone shadowing it
in svn.  Maybe Carsten remembers that conversation because you couldn't
bring yourself to say it then either and Carsten had to explain that was
what you meant.


I will establish a git branch for the canonical kernel while you are
away using the same opaque mokopatch branch layer concept that works on
"andy" branch, and start accepting atomic patches -- hey with
attribution history intact, that'll be nice -- directly in there.

Honestly it's nice that you now realize git will be better than svn, but
since I joined I have literally lost a man-week and more trying to
convince you about that on IRC, email and in person, only to realize I
had spent hours calmly trying to answer realtime nonsense FUD and
apocalyptic scenarios that do not exist in other projects using git and
having veins pop out on my forehead.

A separate but related issue is the path to getting patches into this
canonical git branch.  IMO this needs to be done in a transparent, open
way that takes advantage of the general and domain experts we start to
attract to this list, and that means all patches posted on the list,
considered, and ACK-ed or NAK-ed-with-reasons quickly.  Your old svn
style of multi developer direct repo access is no good for exploiting
the value in this environment.  Hey your argument that we fix
unmonitored trash commits later when someone notices and is willing to
the hassle to complain is okay for an experimental branch (even then it
needs a guiding hand to decide what mix is sensibly let in), but you
propose the canonical branch for this huge, delicate, critical piece of
infrastructure works like that, lol.

If we can't come to an agreement we will have to get the project policy
decided for us by our customer and both of us will have to live with
that result either way.  If the customer says, "no, I want a weirdo
kernel project where people just commit stuff in svn into opaque
patchballs with no review or attribution and the list is worthless", I
will eat it and continue working (until my head explodes anyway).

But the joke here is neither of those "contentious issues" are the
biggest issue for kernel development in this project... they're steps
obvious to anyone else familiar with kernel.org and git.  Wah I dunno
how it looks to normal kernel developers we even have this argument
going on here.

The elephant in the repo is when is the maintainer going to knuckle down
and clear the mokopatches into upstream?  How many 3am sermons did I
hear from this Werner chap about how getting stuff upstream is a
critical goal more critical than shipping the product?  Why do we have
*nothing* upstream since the *start* of the project and the rotting
remains of that work mouldering all around us clogging up new work?

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH1klQOjLpvpq7dMoRAjz/AJ9w2msuk+04N/mdPsELJnn92trZfACgiVpB
3NatN4WtTGG57Y2ifvN1Jp8=
=TJ93
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list