| |||||||||||||
|
| |||||||||||||
Kernel prepatch 2.6.14-rc3Kernel prepatch 2.6.14-rc3Posted Oct 2, 2005 0:25 UTC (Sun) by RMetz (guest, #27939)Parent article: Kernel prepatch 2.6.14-rc3
Does anyone else get the feeling that, true to form, Linus is having trouble not accepting merges he likes as per the new development schedule? By which I mean, accepting only fixes after rc1.
"Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13, and that means that the merge window is closed."
-Linus
Remember that?
I'm not critisizing the man, I just noticed it and thought someone might have something to say.
(Log in to post comments)
Kernel prepatch 2.6.14-rc3 Posted Oct 2, 2005 1:38 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link] well, he said when he released RC1 that there were some patches received just before the release that hw was going to accept, but hadn't made it to rc1.
so I think the real test is going to be from this point on. as it is rc2 has far fewer changes then most of his rc releases have had so it's looking promising.
Kernel prepatch 2.6.14-rc3 Posted Oct 2, 2005 2:16 UTC (Sun) by RMetz (guest, #27939) [Link] Then those patches received right before rc1 were in rc2, I assume. This is rc3 and, correct me if I'm wrong, under the new plan some of the patches in there are not supposed to be.
Kernel prepatch 2.6.14-rc3 Posted Oct 2, 2005 8:13 UTC (Sun) by dvrabel (subscriber, #9500) [Link] I skimmed about 2/3 of the patches before I got bored. All the patches looked suitable for an -rc3. Perhaps you could provide a few example patches that you think should have been delayed for 2.6.15?
Kernel prepatch 2.6.14-rc3 Posted Oct 2, 2005 10:56 UTC (Sun) by Blaisorblade (guest, #25465) [Link] I agree with most other commentors... -rc3 was really quiet, and almost only bugfixes were merged. And you can verify that with git-pull times, over a 56k (yes, I did it).
If you are frightened by the "merge" commits in git history, actually you must realize that they are, mostly, merges from special "high-priority-fixes" branches, with only a few patches.
Indeed, the only problem this time were some core "fixes" which turned out to be wrong (a few days before the release, Roland McGraths fix).
And (on my particular area) one of the latest patches from Al Viro, "UML makefile sanitized", which touches 33 files and broke things for me (yes, the title seems boring, but it isn't).
But IMHO in that case it's the sender who created the problem. In fact, if you look at the changelog, it seems nice and little, even if it can be nasty.
Kernel prepatch 2.6.14-rc3 Posted Oct 2, 2005 20:52 UTC (Sun) by RMetz (guest, #27939) [Link] Why in the name of the FSM would you do a git pull over a 56k line you sick bastard? ; )
All jocularity aside, several gotchas due to patches accepted were reported, I suppose I unfairly assumed they were overly invasive.
Kernel prepatch 2.6.14-rc3 Posted Oct 3, 2005 0:24 UTC (Mon) by proski (subscriber, #104) [Link] Indeed, that's pretty bad because many objects are packed, so you have to pull large packs (line 60 Mb - that's many hours). For repositories that are not packed (e.g. git), one can use "git-fetch -t", which gets the current tree but no historic objects. I cannot wait when the git protocol is supported on kernel.org. Maybe I'll try the Mercurial repository (http://www.kernel.org/hg/linux-2.6/) - Mercurial seems to be more friendly to us, poor dial-up users. Although it's not of much value for me it I cannot track Jeff Garzik's netdev repository.
Kernel prepatch 2.6.14-rc3 Posted Oct 3, 2005 7:16 UTC (Mon) by RMetz (guest, #27939) [Link] Oh, and sorry for the reply to myself, but the key management thing was what really caught my eye. Look at the long change-log. Not a huge deal, and I really don't have a problem with it going in, I just thought stuff like that wasn't going in after rc1.
I'm probably still off on how this is going to work.
Kernel prepatch 2.6.14-rc3 Posted Oct 3, 2005 17:12 UTC (Mon) by iabervon (subscriber, #722) [Link] Actually, most of the present slowness with git (over HTTP) is really roundtrip latency rather than bandwidth. Over a 56K modem, you'd probably be as happy with git as with anything else for getting that much data.
|
|
||||||||||||