-----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-----
