Messages in this thread | | | Date | Wed, 25 Aug 2004 11:13:31 +0200 (MEST) | From | Geert Uytterhoeven <> | Subject | Re: Linux 2.6.9-rc1 |
| |
On Tue, 24 Aug 2004, Linus Torvalds wrote: > On Tue, 24 Aug 2004, Matt Mackall wrote: > > Phew, I was worried about that. Can I get a ruling on how you intend > > to handle a x.y.z.1 to x.y.z.2 transition? I've got a tool that I'm > > looking to unbreak. My preference would be for all x.y.z.n patches to > > be relative to x.y.z. > > Hmm.. I have no strong preferences. There _is_ obviously a well-defined > ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have > any ordering wrt the bugfixes), so either interdiffs or whole new full > diffs are totally "logical". We just have to chose one way or the other, > and I don't actually much care. > > Any reason for your preference?
I prefer diffs between x.y.z.w-1 and x.y.z.w. x.y.z.{...,w-1,w,w+1,...} is one stream of development, x.y.{...,z-1,z,z+1,...} is another one.
BTW, I always found it pretty rare that the rc patches weren't like that. `unpatching' w-1 and `patching' w afterwards isn't fun if you have local changes.
Gr{oetje,eeting}s,
Geert
P.S. Personally I wouldn't suffer from unpatching and patching, since I use merging (using a script that does recursive merges with RCS merge). But if I would not be an architecture maintainer but just a plain user who sometimes does a few hacks (or applies some patches from others) on his kernel, I would just want to apply the x.y.z.w-1-to-x.y.z.w patch, fixup the (hopefully few) rejects, and be happy... -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |