Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Russell, On Sat, 16 Feb 2008 00:09:43 + Russell King <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote: > > I will attempt to build the tree between each merge (and a failed build > > will again cause the offending tree to be dropped). These builds will be > > necessarily restricted to probably one architecture/config. I will build > > the entire tree on as many architectures/configs as seem sensible and > > the results of that will be available on a web page (to be announced). > > This restriction means that the value for the ARM architecture is soo > limited it's probably not worth the hastle participating in this project. > > We already know that -mm picks up on very few ARM conflicts because > Andrew doesn't run through the entire set of configurations; unfortunately > ARM is one of those architectures which is very diverse [*], and because > of that, ideas like "allyconfig" are just completely irrelevant to it. > > As mentioned elsewhere, what we need for ARM is to extend the kautobuild > infrastructure (see armlinux.simtec.co.uk) so that we can have more trees > at least compile tested regularly - but that requires the folk there to > have additional compute power (which isn't going to happen unless folk > stamp up some machines _or_ funding). I now have an arm cross compiler (gcc-4.0.2-glibc-2.3.6 arm-unknown-linux-gnu). (See the results page at http://kisskb.ellerman.id.au/kisskb/branch/9/ - I must get a better name/place :-(.) Is this sufficient to help you out? What configs would be useful to build (as Andrew said, they don't take very long each). I really want as many subsystems as possible in the linux-next tree in an attempt to avoid some of the merge/conflict problems we have had in the past. What can we do to help? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp7FBm2sHObu.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 20, 2008 at 07:13:16PM +0200, Adrian Bunk wrote: > > A third option would be if people add new functions (with no users) in > > -rc2 or -rc3 timeframes as long as it is part of a fully reviewed > > patch with users that will use those new features in various kernel > > development trees. > >... > > I don't like suggestions based on unrealistic assumptions like > "a fully reviewed patch". > > E.g. userspace ABI's are much more stable and everyone is aware that > they must be gotten right with the first try since they are then cast in > stone - but we all remember the recent timerfd fiasco. I'm talking about kernel interfaces, not userspace API's. And we can change them if they are wrong, since they *are* kernel interfaces; but if they correct, they ease the cross-tree merge pain. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 20, 2008 at 10:42:35AM -0500, Theodore Tso wrote: > On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote: > > Two things may largely eliminate the need for parallel branches. > > > > 1. Do infrastructure changes and whole tree wide refactoring etc. in a > > compatible manner with a brief but nonzero transition period. > > > > 2. Insert a second merge window right after the usual merge window for > > changes which cannot be well done with a transition period. > > A third option would be if people add new functions (with no users) in > -rc2 or -rc3 timeframes as long as it is part of a fully reviewed > patch with users that will use those new features in various kernel > development trees. >... I don't like suggestions based on unrealistic assumptions like "a fully reviewed patch". E.g. userspace ABI's are much more stable and everyone is aware that they must be gotten right with the first try since they are then cast in stone - but we all remember the recent timerfd fiasco. > - Ted cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote: > Two things may largely eliminate the need for parallel branches. > > 1. Do infrastructure changes and whole tree wide refactoring etc. in a > compatible manner with a brief but nonzero transition period. > > 2. Insert a second merge window right after the usual merge window for > changes which cannot be well done with a transition period. A third option would be if people add new functions (with no users) in -rc2 or -rc3 timeframes as long as it is part of a fully reviewed patch with users that will use those new features in various kernel development trees. Since there wouldn't be any users in Linus's tree, there's no risk in making those functions available in mainline ahead of time. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Stephen Rothwell wrote: > On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> > wrote: >> >> I absolutely have no problem with having a "this is the infrastrcture >> changes that will go into the next release". In fact, I can even >> *maintain* such a branch. >> >> I've not wanted to open up a second branch for "this is for next release", >> because quite frankly, one of the other problems we have is that people >> already spend way too much time on the next release compared to just >> looking at regressions in the current one. But especially if we're talking >> about _purely_ API changes etc infrastructure, I could certainly do a >> "next" branch. > > So, will you open such a branch? If so, what would be the mechanics of > having patches applied to it? I assume people would have to suggest such > changes explicitly and have them reviewed (hopefully more thoroughly than > usual) in that light. I guess one place these "infrastructure" changes > may be noticed would be when subsystem maintainers stray outside their > subsystem in what they submit to the linux-next tree (or break it). Two things may largely eliminate the need for parallel branches. 1. Do infrastructure changes and whole tree wide refactoring etc. in a compatible manner with a brief but nonzero transition period. 2. Insert a second merge window right after the usual merge window for changes which cannot be well done with a transition period. (I probably missed a number of points why these two things are not always feasible, because I am just a downstream person.) -- Stefan Richter -=-==--- --=- =-=-- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Linus, On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > I absolutely have no problem with having a "this is the infrastrcture > changes that will go into the next release". In fact, I can even > *maintain* such a branch. > > I've not wanted to open up a second branch for "this is for next release", > because quite frankly, one of the other problems we have is that people > already spend way too much time on the next release compared to just > looking at regressions in the current one. But especially if we're talking > about _purely_ API changes etc infrastructure, I could certainly do a > "next" branch. So, will you open such a branch? If so, what would be the mechanics of having patches applied to it? I assume people would have to suggest such changes explicitly and have them reviewed (hopefully more thoroughly than usual) in that light. I guess one place these "infrastructure" changes may be noticed would be when subsystem maintainers stray outside their subsystem in what they submit to the linux-next tree (or break it). Then I assume most people would start working on a merge of this "next" branch and your "master" branch, right? Consequently, each linux-next would also be based on that merge. I suppose I am stating the obvious (or asking the dumb questions), but I always find it easier to have explicit answers to these sorts of things. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] pgpiLBYcwEqCv.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
Frank Seidel wrote: > Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they > also really hope - at least i very strongly do - you not only call on us when > things become a burden, but let us help and assist you right from the start. I just started a little naive webpage where i collected some of the main infos about linux-next on http://linux.f-seidel.de/linux-next/ while the wiki there is probably the best filled part. Does this make any sense to you to continue this? Or do you already have something else in mind or even already prepared? Thanks, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sun, 2008-02-17 at 16:25 +1100, Stephen Rothwell wrote: > Hi James, > > On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > > > > Do you have the tree and build logs available anywhere? I'd like to > > turn off the merge tree builds when this is able to replace it. > > The tree is at > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git - or did > you mean the logs of creating the tree. Yes, the logs of creating the tree. > I currently ceate the tree > fairly manually (as I slowly script what can be) and so have no logs of > that process. Um, well, I've already pointed to tools that currently do this bit automatically. Do you have a list of input trees anywhere? > The build logs that I have some control over are at > http://kisskb.ellerman.id.au/kisskb/branch/9/. I am hoping to expand on > the arch/config combinations over time (I have to convince my tame cross > compiler builder :-)). I also hope that others will build this tree for > themselves and publish the results. Oh, OK ... by build I mean combine the trees and quilts into the actual tree. Compiling is nice, but it's the tree construction logs I want to see to make sure there aren't any impending merge problems. Most people verify on a fairly constant basis that their own trees actually build. The only problems we have are edge configurations (like arm and sparc, which have SCSI drivers that don't build except on those architectures). James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 12:24 -0600, James Bottomley wrote: > Hm ... I think net is a counter example to this. Rebases certainly work > for them. That's a matter of opinion. I'm working on cleaning up the libertas driver as and when I have time, and the constant rebasing of the git trees effectively means that I can't just use git as it was intended; I feel that I'm being forced back into the 1990s by having to deal with sequences of patches instead. It's such a pain that I'm seriously tempted to push my changes directly to Linus instead of through the subsystem maintainers. -- dwmw2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi James, On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > > Do you have the tree and build logs available anywhere? I'd like to > turn off the merge tree builds when this is able to replace it. The tree is at git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git - or did you mean the logs of creating the tree. I currently ceate the tree fairly manually (as I slowly script what can be) and so have no logs of that process. The build logs that I have some control over are at http://kisskb.ellerman.id.au/kisskb/branch/9/. I am hoping to expand on the arch/config combinations over time (I have to convince my tame cross compiler builder :-)). I also hope that others will build this tree for themselves and publish the results. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] pgpCWLR46O0ph.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 2008-02-15 at 12:02 +1100, Stephen Rothwell wrote: > Hi Roland, > > On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote: > > > > For InfiniBand/RDMA, the tree is: > > > > master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git > > for-next > > > > or via git protocol: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git > > for-next > > > > contact addresses (me plus a mailing list): > > > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > Added, thanks. Do you have the tree and build logs available anywhere? I'd like to turn off the merge tree builds when this is able to replace it. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, 13 Feb 2008, Geert Uytterhoeven wrote: > On Tue, 12 Feb 2008, Greg KH wrote: > > On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote: > > > On Tue, 12 Feb 2008, Greg KH wrote: > > > > Perhaps you need to switch to using quilt. This is the main reason why > > > > I use it. > > > > > > Btw, on that note: if some quilt user can send an "annotated history > > > file" > > > of their quilt usage, it's something that git really can do, and I'll see > > > if I can merge (or rather, coax Junio to merge) the relevant part of > > > stgit > > > to make it possible to just basically get "quilt behaviour" for the parts > > > of a git tree that you haven't pushed out yet. > > > > Ted's description matches mine (keep quilt tree in git, edit changelog > > entries, rebase on newer kernel versions, etc.) I can go into details > > if needed. > > Ack. Same for PS3 and m68k (except I don't have the m68k patches in git > (yet)). > > Two issues with using quilt: > 1. Sometimes a patch still applies after it was integrated upstream, Add QUILT_PATCH_OPTS="--fuzz=0" to your ~/.quiltrc file. The default is fuzz=2 IIRC which tries to be too clever. I set fuzz to 0 after I got burned by an unnoticed "quilt patched it somewhere else" bug, which took me half a day to figure out. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, Feb 16, 2008 at 03:42:49AM +0300, Alexey Dobriyan wrote: > On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote: > > On Sat, 16 Feb 2008 00:09:43 + > > Russell King <[EMAIL PROTECTED]> wrote: > > > > > For reference, even _I_ don't build test the entire set of ARM defconfigs > > > - > > > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I > > > just build those which are important to myself, hope that the others are > > > fine, and rely on kautobuild finding any breakage. > > > > > > > you need a better box ;) > > > > cerfcube_defconfig: 35 seconds > > carmeva_defconfig: 23 seconds > > spitz_defconfig (one of the biggest): 45 seconds > > > > so would a stupid `for i in arch/arm/configs/*' script be sufficient > > coverage? > > I do this wildcard together with > > yes '' | make ARCH=arm ... oldconfig > make > > Sans toolchain issues, it's pretty good -- Russell larts you when some > defconfig becomes broken anyway. :^) Only when I check the kautobuild website - which I've not been doing regularly since about end of November, and it only covers Linus' kernels. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, 16 Feb 2008 00:31:36 + Russell King <[EMAIL PROTECTED]> wrote: > > so would a stupid `for i in arch/arm/configs/*' script be sufficient > > coverage? > > It will certainly improve the situation significantly, and pick up > on some non-ARM problems like (badge4_defconfig, since 2.6.24-git2): OK, I'll toss something together. > the latter seems to be because the PCMCIA changes were lost > on the linux-pcmcia list and the trizeps folk have probably given up. I appear to be pcmcia maintainer lately so if someone wants to dust them off and send them over we can see what we can do? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote: > On Sat, 16 Feb 2008 00:09:43 + > Russell King <[EMAIL PROTECTED]> wrote: > > > For reference, even _I_ don't build test the entire set of ARM defconfigs - > > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I > > just build those which are important to myself, hope that the others are > > fine, and rely on kautobuild finding any breakage. > > > > you need a better box ;) > > cerfcube_defconfig: 35 seconds > carmeva_defconfig:23 seconds > spitz_defconfig (one of the biggest): 45 seconds > > so would a stupid `for i in arch/arm/configs/*' script be sufficient > coverage? I do this wildcard together with yes '' | make ARCH=arm ... oldconfig make Sans toolchain issues, it's pretty good -- Russell larts you when some defconfig becomes broken anyway. :^) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote: > On Sat, 16 Feb 2008 00:09:43 + > Russell King <[EMAIL PROTECTED]> wrote: > > > For reference, even _I_ don't build test the entire set of ARM defconfigs - > > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I > > just build those which are important to myself, hope that the others are > > fine, and rely on kautobuild finding any breakage. > > > > you need a better box ;) Maybe - it's a lowly 2.6GHz P4 with 1GB RAM, ICH5, and SATA disk. > cerfcube_defconfig: 35 seconds > carmeva_defconfig:23 seconds > spitz_defconfig (one of the biggest): 45 seconds > > so would a stupid `for i in arch/arm/configs/*' script be sufficient > coverage? It will certainly improve the situation significantly, and pick up on some non-ARM problems like (badge4_defconfig, since 2.6.24-git2): drivers/built-in.o: In function `v4l2_i2c_attach': drivers/media/video/v4l2-common.c:1035: undefined reference to `i2c_attach_client' Currently, the defconfigs known to fail (long term) in Linus' tree are clps7500_defconfig and trizeps4_defconfig - the former I'm tempted to remove, the latter seems to be because the PCMCIA changes were lost on the linux-pcmcia list and the trizeps folk have probably given up. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Russell King wrote: On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote: On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: I wonder why I didn't see any of this - I build arm allmodconfig at least once a week, usually more frequently. Basically, you don't build any of the PXA platforms, which is what was affected. So either the offending patches weren't in my pile or arm allmodconfig is worse than I thought :( It really is in arch maintainers' best interest to keep their allmodconfig in good shape, for this reason. arm's _isn't_ in good shape: the compile fails for several long-standing reasons (eg: no hope of building DRM) and I don't think the coverage is very broad either. I think that Russell has said that allmodconfig isn't very realistic for ARM, with its 70+ config files. Nevertheless, having a usable allmodconfig would be very helpful. Which is quite impossible. I've said all along that all*config is bad news for ARM and folk haven't listened. allmodconfig can (and does) work on some platform configurations such as the one Andrew builds - which will be based on the Versatile platform. However, that doesn't get _any_ of the PXA SoC drivers scattered throughout the tree, the PXA SoC support in arch/arm/mach-pxa, none of the PXA platform support files. If you built an allmodconfig PXA configuration, you'd get those, but you wouldn't get the OMAP SoC drivers, nor the ARM Primecell drivers found on ARMs Integrator, Versatile and Realview platforms and the Cirrus EP93xx SoCs. Nor the Atmel AT91 drivers... and so the list goes on. Each family of platforms are, unfortunately, quite distinct from each other. Does that mean that an artificial allarmconfig can't be made to build? We clearly don't care whether it can boot or work, but we would just as clearly like to be able to build more ARM stuff without N (N > 10) configs. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote: > On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: > > I wonder why I didn't see any of this - I build arm allmodconfig at least > > once a week, usually more frequently. Basically, you don't build any of the PXA platforms, which is what was affected. > > So either the offending patches weren't in my pile or arm allmodconfig is > > worse than I thought :( > > > > It really is in arch maintainers' best interest to keep their allmodconfig > > in good shape, for this reason. arm's _isn't_ in good shape: the compile > > fails for several long-standing reasons (eg: no hope of building DRM) and I > > don't think the coverage is very broad either. > > I think that Russell has said that allmodconfig isn't very realistic > for ARM, with its 70+ config files. Nevertheless, having a usable > allmodconfig would be very helpful. Which is quite impossible. I've said all along that all*config is bad news for ARM and folk haven't listened. allmodconfig can (and does) work on some platform configurations such as the one Andrew builds - which will be based on the Versatile platform. However, that doesn't get _any_ of the PXA SoC drivers scattered throughout the tree, the PXA SoC support in arch/arm/mach-pxa, none of the PXA platform support files. If you built an allmodconfig PXA configuration, you'd get those, but you wouldn't get the OMAP SoC drivers, nor the ARM Primecell drivers found on ARMs Integrator, Versatile and Realview platforms and the Cirrus EP93xx SoCs. Nor the Atmel AT91 drivers... and so the list goes on. Each family of platforms are, unfortunately, quite distinct from each other. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, 16 Feb 2008 00:09:43 + Russell King <[EMAIL PROTECTED]> wrote: > For reference, even _I_ don't build test the entire set of ARM defconfigs - > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I > just build those which are important to myself, hope that the others are > fine, and rely on kautobuild finding any breakage. > you need a better box ;) cerfcube_defconfig: 35 seconds carmeva_defconfig: 23 seconds spitz_defconfig (one of the biggest): 45 seconds so would a stupid `for i in arch/arm/configs/*' script be sufficient coverage? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, 16 Feb 2008 00:05:59 +0100 Roel Kluin <[EMAIL PROTECTED]> wrote: > Alan Cox wrote: > >> Evolution in nature and changes in code are different because in code junk > >> and bugs are constantly removed. In biology junk is allowed and may provide > >> a pool for future development. Linux development is intended and not > >> survival. > > > > I would be interested to see any evidence (rather than intuition) to > > support that, given that both appear to be the same kind of structure and > > that structure is nowadays fairly well understood. > > What do you mean with structure, the evolution? that both are a language? No that they show the same mathematical structure and behaviour - both are scale free networks. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 15:47:24 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: > > > On Fri, 15 Feb 2008 23:23:08 + > > Russell King <[EMAIL PROTECTED]> wrote: > > > > > On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: > > > > I have tried, and successfully done this many times in the past. The > > > > kobject change was one example: add a new function, migrate all users of > > > > a direct pointer over to that function, after that work is all done and > > > > in, change the structure and do the needed work afterward. All is > > > > bisectable completly, with no big "flag day" needed. > > > > > > Incorrect - because this all happened far too quickly. This is one of > > > the reasons that I ended up having to redo various parts of the ARM tree > > > because stuff broke - set_kset_name() completely vanished introducing > > > compile errors, and iirc some merge issues as well. > > > > > > I had patches introducing new system objects which use that, and > > > modifications extremely close to other uses in the PXA code. > > > > > > The end result (through rebuilding the affected parts of my git tree, and > > > asking people for replacement patches) was something that is bisectable - > > > but had I tried to merge stuff as is, it would've been an utter mess, and > > > _was_ unbuildable. > > > > > > > I wonder why I didn't see any of this - I build arm allmodconfig at least > > once a week, usually more frequently. > > > > So either the offending patches weren't in my pile or arm allmodconfig is > > worse than I thought :( > > > > It really is in arch maintainers' best interest to keep their allmodconfig > > in good shape, for this reason. arm's _isn't_ in good shape: the compile > > fails for several long-standing reasons (eg: no hope of building DRM) and I > > don't think the coverage is very broad either. > > I think that Russell has said that allmodconfig isn't very realistic > for ARM, with its 70+ config files. You'd need to pick one board support and enable everything else you possibly can. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote: > I will attempt to build the tree between each merge (and a failed build > will again cause the offending tree to be dropped). These builds will be > necessarily restricted to probably one architecture/config. I will build > the entire tree on as many architectures/configs as seem sensible and > the results of that will be available on a web page (to be announced). This restriction means that the value for the ARM architecture is soo limited it's probably not worth the hastle participating in this project. We already know that -mm picks up on very few ARM conflicts because Andrew doesn't run through the entire set of configurations; unfortunately ARM is one of those architectures which is very diverse [*], and because of that, ideas like "allyconfig" are just completely irrelevant to it. As mentioned elsewhere, what we need for ARM is to extend the kautobuild infrastructure (see armlinux.simtec.co.uk) so that we can have more trees at least compile tested regularly - but that requires the folk there to have additional compute power (which isn't going to happen unless folk stamp up some machines _or_ funding). More trees maintained by more people isn't going to help the situation - if anything, it's going to make it worse - more trees needing more testing by the already extremely limited resources we have available. For reference, even _I_ don't build test the entire set of ARM defconfigs - at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I just build those which are important to myself, hope that the others are fine, and rely on kautobuild finding any breakage. * - plus, its very difficult to get maintainers to see why having a kernel able to support multiple platforms is a good thing. For example, I would absolutely love to be able to combine more platforms into one build (such as Lubbock, Mainstone and probably other PXA stuff), but there's issues with drivers preventing it. (For those two I just mentioned, it's the SMC91x net driver whose build needs to be configured to the precise machine due to the multitude of different ways to connect the hardware to the processor.) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: > On Fri, 15 Feb 2008 23:23:08 + > Russell King <[EMAIL PROTECTED]> wrote: > > > On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: > > > I have tried, and successfully done this many times in the past. The > > > kobject change was one example: add a new function, migrate all users of > > > a direct pointer over to that function, after that work is all done and > > > in, change the structure and do the needed work afterward. All is > > > bisectable completly, with no big "flag day" needed. > > > > Incorrect - because this all happened far too quickly. This is one of > > the reasons that I ended up having to redo various parts of the ARM tree > > because stuff broke - set_kset_name() completely vanished introducing > > compile errors, and iirc some merge issues as well. > > > > I had patches introducing new system objects which use that, and > > modifications extremely close to other uses in the PXA code. > > > > The end result (through rebuilding the affected parts of my git tree, and > > asking people for replacement patches) was something that is bisectable - > > but had I tried to merge stuff as is, it would've been an utter mess, and > > _was_ unbuildable. > > > > I wonder why I didn't see any of this - I build arm allmodconfig at least > once a week, usually more frequently. > > So either the offending patches weren't in my pile or arm allmodconfig is > worse than I thought :( > > It really is in arch maintainers' best interest to keep their allmodconfig > in good shape, for this reason. arm's _isn't_ in good shape: the compile > fails for several long-standing reasons (eg: no hope of building DRM) and I > don't think the coverage is very broad either. I think that Russell has said that allmodconfig isn't very realistic for ARM, with its 70+ config files. Nevertheless, having a usable allmodconfig would be very helpful. --- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 23:23:08 + Russell King <[EMAIL PROTECTED]> wrote: > On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: > > I have tried, and successfully done this many times in the past. The > > kobject change was one example: add a new function, migrate all users of > > a direct pointer over to that function, after that work is all done and > > in, change the structure and do the needed work afterward. All is > > bisectable completly, with no big "flag day" needed. > > Incorrect - because this all happened far too quickly. This is one of > the reasons that I ended up having to redo various parts of the ARM tree > because stuff broke - set_kset_name() completely vanished introducing > compile errors, and iirc some merge issues as well. > > I had patches introducing new system objects which use that, and > modifications extremely close to other uses in the PXA code. > > The end result (through rebuilding the affected parts of my git tree, and > asking people for replacement patches) was something that is bisectable - > but had I tried to merge stuff as is, it would've been an utter mess, and > _was_ unbuildable. > I wonder why I didn't see any of this - I build arm allmodconfig at least once a week, usually more frequently. So either the offending patches weren't in my pile or arm allmodconfig is worse than I thought :( It really is in arch maintainers' best interest to keep their allmodconfig in good shape, for this reason. arm's _isn't_ in good shape: the compile fails for several long-standing reasons (eg: no hope of building DRM) and I don't think the coverage is very broad either. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: > I have tried, and successfully done this many times in the past. The > kobject change was one example: add a new function, migrate all users of > a direct pointer over to that function, after that work is all done and > in, change the structure and do the needed work afterward. All is > bisectable completly, with no big "flag day" needed. Incorrect - because this all happened far too quickly. This is one of the reasons that I ended up having to redo various parts of the ARM tree because stuff broke - set_kset_name() completely vanished introducing compile errors, and iirc some merge issues as well. I had patches introducing new system objects which use that, and modifications extremely close to other uses in the PXA code. The end result (through rebuilding the affected parts of my git tree, and asking people for replacement patches) was something that is bisectable - but had I tried to merge stuff as is, it would've been an utter mess, and _was_ unbuildable. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Alan Cox wrote: >> Evolution in nature and changes in code are different because in code junk >> and bugs are constantly removed. In biology junk is allowed and may provide >> a pool for future development. Linux development is intended and not >> survival. > > I would be interested to see any evidence (rather than intuition) to > support that, given that both appear to be the same kind of structure and > that structure is nowadays fairly well understood. What do you mean with structure, the evolution? that both are a language? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Linus Torvalds wrote: > > On Wed, 13 Feb 2008, Roel Kluin wrote: >> In nature there is a lot of duplication: several copies of genes can exist >> and different copies may have a distinct evolution. > > This is true of very complex animals, but much less so when looking at > things like bacteria (and arguably, any current sw project is closer to > bacteria in complexity than anything mammalian). > > In bacteria (and viruses), duplication of DNA/RNA is a big cost of living > in general, and as a result there is *much* less junk DNA. So in an > evolutionary sense, it's much closer to what the kernel should have (with > occasional duplication of code and interfaces to allow new functionality, > but rather aggressive pruning of the excess baggage). I like the comparison, and while I wrote my comment I have to admit I was also thinking of bacteria and virusses as an exception: There the speed of replication can be an important factor for survival. Less DNA means faster replication and therefore the pressure is on removal of junk DNA. It can be disputed however that removal of 'junk sourcecode' is a survival factor for the linux kernel but the benefit may be disputable as well. > In other words, all of these choices are a matter of "balance". In some > areas, excess code is not a sufficient downside, and we keep even broken > source code around with no actual function, "just because" (or rather, > because the cost of carrying it around is so small that nobody cares). > > That's true in the kernel as in biology: check out not just deprecated > code, but the drivers and other odds-and-ends that are explicitly marked > as non-coding DNA (we just happen to call them BROKEN in our Kconfig). > > Linus Maybe we can elaborate a bit on this comparison, just for fun: I think not the linux kernel alone, but rather the entire Linux OS could be compared with a cell. The kernel source encodes vital software parts including the interactions with hardware - the environment for the computer. Gcc can be compared with the (transcription and) translation machinery. DNA can be seen as a language that encodes proteins, with biological functions: Some are vital, including ones that allow interactions with the environment: The cellular environment is beyond the membrane. Interactions occur through membrane receptors, channels, etc. Interaction between proteins can be compared with functions selectively calling other functions. Activation of certain proteins can cause a cascade of protein interactions, comparable with function calls in a loop: the activated protein activates particular protein(s) several times. Some proteins influence intracellular messengers: cellular global variables. Transmembrane receptors responding to extracellular signals transmit this through conformational changes across the membrane to the intracellular region: These structural changes may allow interactions with new proteins. Maybe comparable with a combination of hardware interrupts, signals and the userspace? The response to extracellular signals often depends on several sequential interactions between proteins. This provides a protective layer that can be compared with the kernelspace layer. This is where the comparison probably becomes too biased to continue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, Feb 14, 2008 at 07:35:03PM +0200, Benny Halevy wrote: > One idea that I thought about when debating rebase vs. merge (and it's > far far from being fully baked) is versioned commits. The gist of it > is that patches are assigned an hash identifier like today when they > are first committed into the tree, but, and this is the main change: > if they mutate, e.g. by a rebase, or even git commit --amend, their > version is bumped up rather than SHA changed. The SHA1 is uniquely determined by the contents of that commit--commit and author names and times, changelog message, snapshot of the tree at that point, and parents--hence, recursively, by the entire history leading up to that commit. Naming objects by their content in that way has a lot of advantages--for example, you can sign an entire history by signing just the SHA1 of the commit at its tip. So you can't break that link between the names of commits and their contents without ending up with a fundamentally different (and probably weaker, in some sense), system. I suspect there's an unavoidable tradeoff--if you want to be able to reliably and efficiently determine how two branches are related, then you can't just throw away their (possibly messy) history. The best you may be able to do, if you want the advantages of both rebasing and merging, is to maintain on your own the messier meta-history as a superset of the simpler history that you end up submitting. --b. > This way all versions of the commit would be accessible and addressable using > their respective SHA *and* version. I think that this can help keep > the tree's history in a more intuitive way (since the patches' base identifier > won't change, just its version number), and you get a bonus of seeing each > commit's history, who changed it, and what was the change. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 04:26:45 EST, Gene Heskett said: > On Friday 15 February 2008, [EMAIL PROTECTED] wrote: > >On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said: > >> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are > >> appearing to indicate its not a problem until some distro actually ships a > >> kernel with the changes that broke it. That could be months or even a > >> year plus. > > > >Actually following the NVidia forums indicates otherwise: > > > >http://www.nvnews.net/vbulletin/showthread.php?t=107144 > > > >I expect Zander will be posting a patch rather soonish, for some value of > >soonish. And if you're running a -rc or -mm kernel, patching the 169.09 > >drivers should be well within your abilities > > Not so for the binaries, existing patches do make it compile but it still > upchucks someplace in the binary, or was this time yesterday. Umm.. if you actually *read* the mentioned thread, you'll see that "existing patches" are known to be incomplete, complete with the "upchucks in the binary" (mentioned at entry number 9 of the thread), and that Zander already knows about it (entry #11), and has apparently one remaining issue left to resolve (entries #32 and #36). And entry #36 is what the NVidia engineer doing the work was thinking about 20 hours ago. Interpret it as you will... pgpL0bWoIfZJW.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
On Friday 15 February 2008, [EMAIL PROTECTED] wrote: >On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said: >> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are >> appearing to indicate its not a problem until some distro actually ships a >> kernel with the changes that broke it. That could be months or even a >> year plus. > >Actually following the NVidia forums indicates otherwise: > >http://www.nvnews.net/vbulletin/showthread.php?t=107144 > >I expect Zander will be posting a patch rather soonish, for some value of >soonish. And if you're running a -rc or -mm kernel, patching the 169.09 >drivers should be well within your abilities Not so for the binaries, existing patches do make it compile but it still upchucks someplace in the binary, or was this time yesterday. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) It is not well to be thought of as one who meekly submits to insolence and intimidation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, 14 Feb 2008 12:32:29 PST, Greg KH said: > How about "weeks". Both Fedora and openSUSE's next release is going to > be based on 2.6.25, and the first round of -rc1 kernels should be > showing up in their trees in a few days. So for this instance, I think > you will be fine :) a few days == *NOW* kernel-2.6.25-0.40.rc1.git2.fc9.x86_64 is in Fedora Rawhide already. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said: > Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing > to > indicate its not a problem until some distro actually ships a kernel with the > changes that broke it. That could be months or even a year plus. Actually following the NVidia forums indicates otherwise: http://www.nvnews.net/vbulletin/showthread.php?t=107144 I expect Zander will be posting a patch rather soonish, for some value of soonish. And if you're running a -rc or -mm kernel, patching the 169.09 drivers should be well within your abilities -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Thu, 14 Feb 2008, Stephen Rothwell wrote: > > > > Originally, I assumed the stable branch would be for our "usual" API > > changes, but it appears we are not having any more of those. :-) > > It's not that we should _never_ have them, it's that they shouldn't be > "business as usual". > > I'm happy with them being a "a couple of times a year". I'm not happy > with them being "once or twice for every release cycle". That's the > big deal for me. very much agreed. I've yet to see a _single_ wide-scale API change that broke stuff left and right where that breakage was technically justified. I have not seen a single one. All those cases were just plain old botched attempts. Either someone can do a large-scale API change like the irq_regs() cleanups with near-zero breakages, or someone cannot. In the latter case, gradual introduction and trickling it through subsystem trees is a _must_. and if it's _hard_ to do a particular large-scale change, then i think the right answer is to _not do it_ in a large-scale way, but do it gradually. I claim that there's just not a single valid case of doing wide-scale changes atomically and departing from the current to-be-stabilized kernel tree materially. _Every_ large-scale API change can be done in a staged way, with each subsystem adopting to the change at their own pace, it just has to be planned well and tested well enough and has to be executed persistently. And the moment we trickle things through subsystem trees, there's no integration pain, as subsystem trees are largely disjunct anyway. i also fear that having an API-changes-only tree will dillute our testing effort of the current to-be-stabilized upstream tree, as it materially disrupts the flow of patches. Most maintainers should concentrate on stabilizing current -git with only one serial queue of fixes and enhancements ontop of that tree. I dont see how having a second queue would help - it clearly splits attention. widescale API changes should be discouraged, and forcing them through the harder, "gradual, per subsystem" route is _exactly_ such a strong force that discourages people from doing them. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Roland, On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote: > > For InfiniBand/RDMA, the tree is: > > master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-next > > or via git protocol: > > git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git > for-next > > contact addresses (me plus a mailing list): > > [EMAIL PROTECTED] > [EMAIL PROTECTED] Added, thanks. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpQbcvvTYcj6.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
> The first things I need from the subsystem maintainers (you know who you > are) are a contact address (a list address is fine) and at least one git > branch or quilt series that contains all the things you want to see go > into 2.6.26. For InfiniBand/RDMA, the tree is: master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-next or via git protocol: git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-next contact addresses (me plus a mailing list): [EMAIL PROTECTED] [EMAIL PROTECTED] thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
On Thu, Feb 14, 2008 at 01:56:13AM +0100, Roman Zippel wrote: > Hi, > > On Wednesday 13. February 2008, Sam Ravnborg wrote: > > > config foo > > tristate "do you want foo?" > > depends on USB && BAR > > module > > obj-$(CONFIG_FOO) += foo.o > > foo-y := file1.o file2.o > > help > > foo will allow you to explode your PC > > I'm more thinking about something like this: > > module foo [FOO] > tristate "do you want foo?" > depends on USB && BAR > source file1.c > source file2.c if BAZ > > Avoiding direct Makefile fragments would give us far more flexibility in the > final Makefile output. Much better and now I see it I recall you posted something along these lines before. Is this something that you plan to look into implementing? I can do the kbuild bits but I need you to do the kconfig stuff (which is by far the biggest effort too). It would be much appreciated to get this. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thursday 14 February 2008, Greg KH wrote: >On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote: >> On Thursday 14 February 2008, Linus Torvalds wrote: >> [...] >> >> >And this is where "process" really matters. Making sure people don't get >> >too frustrated about the constant grind. >> >> One of the problems caused by this 'grind' is being locked out of using >> 3rd party closed drivers until the vendor decides its stable enough to >> make the effort to update their binary blobs to match the newer functions. >> >> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are >> appearing to indicate its not a problem until some distro actually ships a >> kernel with the changes that broke it. That could be months or even a >> year plus. > >How about "weeks". Both Fedora and openSUSE's next release is going to >be based on 2.6.25, and the first round of -rc1 kernels should be >showing up in their trees in a few days. So for this instance, I think >you will be fine :) > >thanks, That is good news, thanks Greg. > >greg k-h -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) There's small choice in rotten apples. -- William Shakespeare, "The Taming of the Shrew" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote: > On Thursday 14 February 2008, Linus Torvalds wrote: > [...] > >And this is where "process" really matters. Making sure people don't get > >too frustrated about the constant grind. > > One of the problems caused by this 'grind' is being locked out of using 3rd > party closed drivers until the vendor decides its stable enough to make the > effort to update their binary blobs to match the newer functions. > > Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing > to > indicate its not a problem until some distro actually ships a kernel with the > changes that broke it. That could be months or even a year plus. How about "weeks". Both Fedora and openSUSE's next release is going to be based on 2.6.25, and the first round of -rc1 kernels should be showing up in their trees in a few days. So for this instance, I think you will be fine :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thursday 14 February 2008, Linus Torvalds wrote: [...] >And this is where "process" really matters. Making sure people don't get >too frustrated about the constant grind. One of the problems caused by this 'grind' is being locked out of using 3rd party closed drivers until the vendor decides its stable enough to make the effort to update their binary blobs to match the newer functions. Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing to indicate its not a problem until some distro actually ships a kernel with the changes that broke it. That could be months or even a year plus. So you've lost one 'canary in the coal mine' tester at least until that happens as I don't have a spare box I can setup to run the nv driver, which itself seems to be suffering from bit rot recently and cannot run this screen at its native 1680x1050 resolution, reverting to something that resembles what I used to get from a timex 1000 in 1978 but with a few colors. I just recently had to install the nvidia driver on my milling machines kubuntu 6.06 box cuz an xorg update put it back to 640x400 if the nv driver was used. This is the real world, where politics aside, it just has to work... :-( But I'll still be lurking and building to test anyway even if I don't boot it for more than 10 minutes. :) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) I'm not a lawyer. I don't even play one on TV. - Linus Torvalds on the gcc mailing list -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, 14 Feb 2008, Stephen Rothwell wrote: > > Originally, I assumed the stable branch would be for our "usual" API > changes, but it appears we are not having any more of those. :-) It's not that we should _never_ have them, it's that they shouldn't be "business as usual". I'm happy with them being a "a couple of times a year". I'm not happy with them being "once or twice for every release cycle". That's the big deal for me. If we have a big flag-day that affects a lot of drivers (or architectures) once or twice a year, I think everybody involved will be happy to stand up and say "ok, that fixes problem X, and the new thing really is better, so let's do it, it's worth it". But if it's something that happens essentially every single release, that is somethign else altogether. Then it's not a "ok, let's bite the bullet and make the kernel better" thing any more, but instead it devolves into "f*ck, the merge window is open again, now I have to fix up all the crap people pushed on me". See? That's a *huge* difference, even if it is "only" a mental one (and clearly it isn't - there's the actual real work of the "I have to fix things up" part too). So to recap: I have absolutely nothing against fixing up bad internal API's and breaking things. But 99% of the time that should be something we can do incrementally (ie introduce the new API, and simply accept the fact that removing the old API will take a few months). And the case when that _really_ doesn't work should be rare enough that it doesn't wear people down. Because if you listen to the tone of people in this discussion, much of it is about people being _tired_ of having to fix things up. It's not exactly been a "wow, the end result sure was nice!" kind of discussion, is it? And this is where "process" really matters. Making sure people don't get too frustrated about the constant grind. > However, > I see an argument for attempting to stabilise possible conflicting > changes get Linus' review/ack and add them to the stable branch. > > Linus suggested that such changes should go into an independent tree that > everyone could pull into their trees with the full confidence that that > tree would be merged into Linus' tree when the merge window opens. I am > suggesting that that tree be the stable branch of linux-next. I absolutely have no problem with having a "this is the infrastrcture changes that will go into the next release". In fact, I can even *maintain* such a branch. I've not wanted to open up a second branch for "this is for next release", because quite frankly, one of the other problems we have is that people already spend way too much time on the next release compared to just looking at regressions in the current one. But especially if we're talking about _purely_ API changes etc infrastructure, I could certainly do a "next" branch. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Feb. 13, 2008, 19:52 +0200, "J. Bruce Fields" <[EMAIL PROTECTED]> wrote: > On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote: >> So just the fact that the right commit gets blamed when somebody does a >> "git bisect" is I think a big issue. It's just fundamentally more fair to >> everybody. And it means that the people who push their work to me can >> really choose to stand behind it, knowing that whatever happens, their >> work won't get diluted by bad luck or others' incompetence. >> >> And no, maybe most people don't feel things like that matters. But I do >> think it's important. > > The obvious advantage to rebasing in this case is that the blame > (misplaced though it may be), at least lands on a commit that made a > single small change, likely making the problem easier to diagnose. > > (As opposed to the case of a large merge, where all you may know is that > somewhere in the hundreds of commits done on one side of the merge there > was a conflict with the hundreds of commits on the other side.) > > I think a lot of people would see rebasing as an acceptable tradeof that > gives up a small amount of accuracy in assigning blame to individuals in > return for a large increase in ability to debug problems. > > I suppose one response to that would be that it's important that people > learn how to work in parallel, that failures to do so are particularly > important failures in the process, and that it's therefore worth it to > make sure that such failures are always identified specifically as merge > failures. > > It would be nice if merges, like patches, were broken up into somewhat > smaller units. There's an understandable desire to wait to the last > minute to actually commit to one's commits, but a willingness to do so a > little earlier might avoid some of the problems that seem to come from > having a lot of large merges happen all at once. > > --b. One idea that I thought about when debating rebase vs. merge (and it's far far from being fully baked) is versioned commits. The gist of it is that patches are assigned an hash identifier like today when they are first committed into the tree, but, and this is the main change: if they mutate, e.g. by a rebase, or even git commit --amend, their version is bumped up rather than SHA changed. This way all versions of the commit would be accessible and addressable using their respective SHA *and* version. I think that this can help keep the tree's history in a more intuitive way (since the patches' base identifier won't change, just its version number), and you get a bonus of seeing each commit's history, who changed it, and what was the change. Benny -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Russell, On Thu, 14 Feb 2008 08:14:05 + Russell King <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote: > > We need to ask Linus to promise that he will pull the stable branch from > > linux-next first in the merge window. For that to happen, I would expect > > that Linus would also review and sign off (or ack) these commits to the > > linux-next tree. > > Changing the commits in git in anyway changes their ID, which has the > same effects as a rebase. Correct. > With this idea, Linus only has two choices: > > 1. pull the entire set of linux-next changes whether he likes them or not, >because he's going to get them either from the linux-next tree or someone >elses tree which is based upon that. > > 2. don't pull the changes, nor anyone elses tree if he hates the changes >in linux-next. > > So really, Linus needs to ack the changes _before_ they go into linux-next. This is exactly what I suggested (or meant to) *except* that I want it to only apply to the stable branch. I intend that the stable branch of linux-next will never be rebased and so is suitable for others to base their trees off. The master branch will be continually rebased as the subsystem trees change over time. Originally, I assumed the stable branch would be for our "usual" API changes, but it appears we are not having any more of those. :-) However, I see an argument for attempting to stabilise possible conflicting changes get Linus' review/ack and add them to the stable branch. Linus suggested that such changes should go into an independent tree that everyone could pull into their trees with the full confidence that that tree would be merged into Linus' tree when the merge window opens. I am suggesting that that tree be the stable branch of linux-next. I know I haven't thought through all the consequences of this, so discussion is encouaged. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpwL5SPwbFr7.pgp Description: PGP signature
Re: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
On Thu, 14 Feb 2008, Roman Zippel wrote:
> On Wednesday 13. February 2008, Sam Ravnborg wrote:
> > config foo
> > tristate "do you want foo?"
> > depends on USB && BAR
> > module
> > obj-$(CONFIG_FOO) += foo.o
> > foo-y := file1.o file2.o
> > help
> > foo will allow you to explode your PC
>
> I'm more thinking about something like this:
>
> module foo [FOO]
> tristate "do you want foo?"
> depends on USB && BAR
> source file1.c
> source file2.c if BAZ
And we can finally distinguish between
config bar
bool "do you want bar?"
for boolean options and
module baz
bool "do you want baz?"
for modules that cannot be modular?
And we can make `depends on' do the right thing for dependencies on modules
that are modular (cfr. e.g. commit e11a6c236b3070ed05b079f91a9b3defa48b54d3,
[VIDEO]: XVR500 and XVR2500 require FB=y)?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote: > We need to ask Linus to promise that he will pull the stable branch from > linux-next first in the merge window. For that to happen, I would expect > that Linus would also review and sign off (or ack) these commits to the > linux-next tree. Changing the commits in git in anyway changes their ID, which has the same effects as a rebase. With this idea, Linus only has two choices: 1. pull the entire set of linux-next changes whether he likes them or not, because he's going to get them either from the linux-next tree or someone elses tree which is based upon that. 2. don't pull the changes, nor anyone elses tree if he hates the changes in linux-next. So really, Linus needs to ack the changes _before_ they go into linux-next. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
Hi, On Wednesday 13. February 2008, Sam Ravnborg wrote: > config foo > tristate "do you want foo?" > depends on USB && BAR > module > obj-$(CONFIG_FOO) += foo.o > foo-y := file1.o file2.o > help > foo will allow you to explode your PC I'm more thinking about something like this: module foo [FOO] tristate "do you want foo?" depends on USB && BAR source file1.c source file2.c if BAZ Avoiding direct Makefile fragments would give us far more flexibility in the final Makefile output. > And we could introduce support for > > source "drivers/net/Kconfig.*" > > But then we would have to make the kconfig step mandatory > for each build as we would otherwise not know if there > were added any Kconfig files. That's a real problem and it would be a step back of what we have right now, so I'm not exactly comfortable with it. bye, Roman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 13, 2008 at 01:24:41PM -0700, Ann Davis wrote: > Frank Seidel wrote: >> >> Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they >> also really hope - at least i very strongly do - you not only call on us when >> things become a burden, but let us help and assist you right from the start. > > Agreed. I'm happy to do daily builds (I have x86 and ppc systems > available), >... Jan already does builds of all -git (and previously -bk) and -mm kernels for all architectures for some years, and it might be easier if he simply adds -next to his builds. > Thx, > > Ann cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Frank Seidel wrote: Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they also really hope - at least i very strongly do - you not only call on us when things become a burden, but let us help and assist you right from the start. Agreed. I'm happy to do daily builds (I have x86 and ppc systems available), write scripts, etc. In the meantime I'll just lurk and learn. :-) Thx, Ann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
> Evolution in nature and changes in code are different because in code junk > and bugs are constantly removed. In biology junk is allowed and may provide > a pool for future development. Linux development is intended and not > survival. I would be interested to see any evidence (rather than intuition) to support that given that both appear to be the same kind of structure and that structure is nowdays fairly well understood. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, 13 Feb 2008, Roel Kluin wrote: > > In nature there is a lot of duplication: several copies of genes can exist > and different copies may have a distinct evolution. This is true of very complex animals, but much less so when looking at things like bacteria (and arguably, any current sw project is closer to bacteria in complexity than anything mammalian). In bacteria (and viruses), duplication of DNA/RNA is a big cost of living in general, and as a result there is *much* less junk DNA. So in an evolutionary sense, it's much closer to what the kernel should have (with occasional duplication of code and interfaces to allow new functionality, but rather aggressive pruning of the excess baggage). In other words, all of these choices are a matter of "balance". In some areas, excess code is not a sufficient downside, and we keep even broken source code around with no actual function, "just because" (or rather, because the cost of carrying it around is so small that nobody cares). That's true in the kernel as in biology: check out not just deprecated code, but the drivers and other odds-and-ends that are explicitly marked as non-coding DNA (we just happen to call them BROKEN in our Kconfig). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 13, 2008 at 05:36:41AM -0500, Theodore Tso wrote: > On Tue, Feb 12, 2008 at 10:16:53PM -0800, Greg KH wrote: > > I was amazed at how slow stgit was when I tried it out. I use > > git-quiltimport a lot and I don't think it's any slower than just using > > quilt on its own. So I think that the speed issue should be the same. > > I like using "guilt" because I can easily reapply the patchset using > "guilt push -a", which is just slightly fewer characters to type than > "git-quiltimport". This also means that I don't need to switch back > and forth between "git mode" and "quilt mode" when I'm editing the > patches (either directly by editing the patch files, in which case > afterwards I do a "guilt pop -a; guilt push -a", or by using "guilt > pop", "guilt push", and "guilt refresh"). I had problems getting guilt to preserve metadata properly last time I tried it, and it forced me to work with the same location and format that the original developers used, which wasn't as flexable as quilt could handle from what I recall. But I'll try it again, it might have gotten better... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 09:09:34AM -0800, Linus Torvalds wrote: >... > The other is that once somebody says "ok, I *really* need to cause this > breakage, because there's a major bug or we need it for fundamental reason > XYZ", then that person should > > (a) create a base tree with _just_ that fundamental infrastructure change, > and make sure that base branch is so obviously good that there is no > question about merging it. > > (b) tell other people about the reason for the infrastructure change, and > simply allow others to merge it. You don't have to wait for *me* to > open the merge window, you need to make sure that the people that get > impacted most can continue development! > > This is where "rebases really are bad" comes in. When the above sequence > happens, the fundamental infrastructure change obviously does need to be > solid and not shifting under from other people who end up merging it. I do > not want to see five different copies of the fundamental change either > because the original source fixed it up and rebased it, or because the > people who merged it rebased _their_ trees and rebased the fundamental > change in the process. > > Can that (b) be my tree? Sure. That's been the common case, and I'll > happily continue it, of course, so I'm not arguing for that to go away. > Merging is my job, I'll do it. But when the merge window is a problem, my > merge window should *not* hold up people from using the distributed nature > of git for their advantage. > > But yes, obviously when doing cross-merges, you'd better be really > *really* sure that the base is solid and will get merged. But let's face > it, all the really core maintainers should damn well know that by now: > you've all worked with me for years, so you should be able to trivially be > able to tell whether you *might* need to worry about something, and when > it's a slam dunk. > > And it's the "it's a slam dunk" cases that I think are (a) the common ones > and (b) the ones where you can just do cross-merges to satisfy each others > needs. > > Hmm? Does that sound palatable to people? I'm sure I understand only less than half of what you said. My current understanding is that all the aspects of your proposal that are interesting for me can be summarized as follows: - your tree stops compiling at the beginning of the merge window when you merge the first subsystem tree - your tree might compile again at the end of the merge window when you merge the last subsystem tree - git-bisect -> /dev/null What do I miss? > Linus cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote: > So just the fact that the right commit gets blamed when somebody does a > "git bisect" is I think a big issue. It's just fundamentally more fair to > everybody. And it means that the people who push their work to me can > really choose to stand behind it, knowing that whatever happens, their > work won't get diluted by bad luck or others' incompetence. > > And no, maybe most people don't feel things like that matters. But I do > think it's important. The obvious advantage to rebasing in this case is that the blame (misplaced though it may be), at least lands on a commit that made a single small change, likely making the problem easier to diagnose. (As opposed to the case of a large merge, where all you may know is that somewhere in the hundreds of commits done on one side of the merge there was a conflict with the hundreds of commits on the other side.) I think a lot of people would see rebasing as an acceptable tradeof that gives up a small amount of accuracy in assigning blame to individuals in return for a large increase in ability to debug problems. I suppose one response to that would be that it's important that people learn how to work in parallel, that failures to do so are particularly important failures in the process, and that it's therefore worth it to make sure that such failures are always identified specifically as merge failures. It would be nice if merges, like patches, were broken up into somewhat smaller units. There's an understandable desire to wait to the last minute to actually commit to one's commits, but a willingness to do so a little earlier might avoid some of the problems that seem to come from having a lot of large merges happen all at once. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 12:50:51PM -0800, Greg KH wrote: > On Tue, Feb 12, 2008 at 07:46:51PM +, Al Viro wrote: >... > > AFAICS, we are in situation when review bandwidth is where the bottleneck > > is. Not the merge one... > > Are there still large numbers of posted patches, not reviewed or picked > up by anyone laying around somewhere? I thought Andrew-the-patch-vacuum > had been doing a great job of keeping that from happening lately. I wrote in one of the many bug reports I sent for compile errors introduced in Linus' tree during this merge window: An architecture specific patch that breaks the one architecture it touches at the first file being compiled is even for kernel standards unusually bad... > thanks, > > greg k-h cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Linus Torvalds wrote: > > On Tue, 12 Feb 2008, Greg KH wrote: >>> That's the point. >> Not it isn't. To quote you a number of years ago: >> "Linux is evolution, not intelligent design" > > Umm. Have you read a lot of books on evolution? > > It doesn't sound like you have. > > The fact is, evolution often does odd (and "suboptimal") things exactly > because it does incremental changes that DO NOT BREAK at any point. This is not entirely true if the pressure for changes are removed. For instance in mammals the bones in the ear are what used to be gills in fish. When fish became amphibians the gills weren't needed as much and evolution took a side path. > The examples are legion. The mammalian eye has the retina "backwards", > with the blind spot appearing because the fundmanetal infrastructure (the > optical nerves) actually being in *front* of the light sensor and needing > a hole in the retina to get the information (and blood flow) to go to the > brain! > > In other words, exactly *because* evolution requires "bisectability" (any > non-viable point in between is a dead end by definition) and does things > incrementally, it doesn't do big flips. It fixes the problems on an > incremental scale both when it comes to the details and when it comes to > both "details" (actual protein-coding genes that code directly for some > expression) and "infrastructure" (homeobox and non-coding genes). In nature there is a lot of duplication: several copies of genes can exist and different copies may have a distinct evolution. There is also a lot of 'junk' DNA that doesn't code for anything (although it may have regulating functions). In there some copies of genes may remain that are inactivated, as well as parts of virusses, slowly obtaining random mutations because there is no pressure on the evolution of them. Some may eventually become active again and have different functions. The duplication also often ensures there is fallback when random mutations are acquired and a protein is knocked out. Besides the two chromosomes several proteins also can have overlapping functions. The result is more like a balance. Evolution in nature and changes in code are different because in code junk and bugs are constantly removed. In biology junk is allowed and may provide a pool for future development. Linux development is intended and not survival. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 13, 2008 at 10:06:16AM -0500, John W. Linville wrote: > On Tue, Feb 12, 2008 at 06:47:30PM -0800, Joel Becker wrote: > > Make the distinction earlier. With ocfs2 and configfs (we got > > this scheme from Jeff), we keep the topic branches as "unsafe" - that > > is, officially rebaseable . We merge them all into a big "ALL" branch, > > which is also "unsafe". Andrew pulls this for -mm, and it gets tested > > here. If there is a brown-paper-bag problem, we can tell the original > > author to fix it. Then we re-pull the topic - effectively a rebase. > > The ALL is also rebased. But that's Ok, it will never go towards Linus. > > This is essentially the same process I've been using in wireless-2.6 > with the (regularly rebased) 'everything' branch. Still I find > that it causes lots of confusion and complaining. Perhaps I am not > communicating clearly enough... :-) > > Do you find that people are happy with that process? Forgive me for > not knowing, but how many developers are actively (or occasionaly) > involved in ocfs2 and configfs? How many 'normal' users pull your > tree looking for 'latest and greatest' code? Oh, I have no pretense that ocfs2 is as busy as wireless or net. Certainly Andrew has no problem with it. People I've interacted with while working on features, etc, also get it, but I'm usually pointing them to it up-front. I think you'd probably have lessons that larger trees could learn from. For example, do you have a 'things that will go to linus soon" branch that people can grab - something that's now stable/non-rebasing? Do you advertise the rebaseableness of "everything" in the web page where you say "grab 'everthing' for the latest stuff"? Joel -- "The suffering man ought really to consume his own smoke; there is no good in emitting smoke till you have made it into fire." - thomas carlyle Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 06:47:30PM -0800, Joel Becker wrote: > Make the distinction earlier. With ocfs2 and configfs (we got > this scheme from Jeff), we keep the topic branches as "unsafe" - that > is, officially rebaseable . We merge them all into a big "ALL" branch, > which is also "unsafe". Andrew pulls this for -mm, and it gets tested > here. If there is a brown-paper-bag problem, we can tell the original > author to fix it. Then we re-pull the topic - effectively a rebase. > The ALL is also rebased. But that's Ok, it will never go towards Linus. > When a topic is considered worthy of going upstream, we pull it > to a branch called "upstream-linus". This branch is *NEVER* rebased. > Now that the topic is in upstream-linus, the original topic branch can't > be rebased either. So any fixes to that topic going forward will stay > in the history. Since that topic was pulled into ALL for testing, we > are using the identical commits that got tested. This is essentially the same process I've been using in wireless-2.6 with the (regularly rebased) 'everything' branch. Still I find that it causes lots of confusion and complaining. Perhaps I am not communicating clearly enough... :-) Do you find that people are happy with that process? Forgive me for not knowing, but how many developers are actively (or occasionaly) involved in ocfs2 and configfs? How many 'normal' users pull your tree looking for 'latest and greatest' code? John -- John W. Linville [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Stephen Rothwell wrote: > On Tue, 12 Feb 2008 12:02:08 +1100 Stephen Rothwell wrote: >> Andrew was looking for someone to run a linux-next tree that just >> contained the subsystem git and quilt trees for 2.6.x+1 and I (in a >> moment of madness) volunteered. > > I neglected to mention the other brave souls who volunteered: Frank > Seidel, Ann Davis, and Harvey Harrison who I hope to be able to call on > in times of need. Hey, I'm sure you just temporarily forgot the discussion about that point we had the days before ;-) Never mind, just kidding! :-) Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they also really hope - at least i very strongly do - you not only call on us when things become a burden, but let us help and assist you right from the start. Thanks, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 13, 2008 at 07:06:24AM -0500, Jeff Garzik wrote: > Russell King wrote: > >We know that the -mm tree is pretty much useless in terms of code > >coverage for ARM, and it's getting increasingly unlikely that anything > >short of a build of all ARM defconfigs will pick up on merge issues - > >which is a lot of CPU cycles, and I'm not going to insist its something > >that should be done. > > > If you need help in that area (build-testing ARM), surely we can find > some fast machines that can do builds for you. Any interest? It would probably make some sense - it would help to get hold of the infrastructure that armlinux.simtec.co.uk uses to run their test builds of Linus' tree and apply it (on a separate machine) to -mm (or indeed whatever other) kernels. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Russell King wrote: We know that the -mm tree is pretty much useless in terms of code coverage for ARM, and it's getting increasingly unlikely that anything short of a build of all ARM defconfigs will pick up on merge issues - which is a lot of CPU cycles, and I'm not going to insist its something that should be done. If you need help in that area (build-testing ARM), surely we can find some fast machines that can do builds for you. Any interest? Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 22:16 -0800, Greg KH wrote: > Ted's description matches mine (keep quilt tree in git, edit changelog > entries, rebase on newer kernel versions, etc.) I can go into details > if needed. I added some time ago patch history tracking in stgit and you can run "stg log [--graphical] " to see all the changes for that patch (as a list or via gitk). This is done by keeping a separate DAG of commits linking small changes to a patch. > I was amazed at how slow stgit was when I tried it out. I use > git-quiltimport a lot and I don't think it's any slower than just using > quilt on its own. So I think that the speed issue should be the same. It shouldn't be slower than git-quiltimport (at least the recent stgit versions) as they seem to have a similar approach (using "git apply"). There is probably an extra check stgit does for local changes before starting the import. Otherwise, just use git-quiltimport and "stg uncommit" to generate the patches. StGIT approach for pushing patches is to use git-apply and, only if this fails, switch to a three-way merge. These days it seems that the three-way merge is pretty fast anyway, we might drop the former (after some benchmarking). > I had a number of issues last time I tried stgit out, but maybe they are > now resolved, I'll try it out tomorrow and report to the git list > anything I find that doesn't work for me. Please try the last stable release, 0.14. The current HEAD has some restructuring done (but gets nice features like transactions, undo). Thanks. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 21:16 -0500, Theodore Tso wrote: > I've never been very happy with stgit because of past experiences > which has scarred me when it got get confused and lost my entire patch > series (this was before git reflogs, so recovery was interesting). It got much better now :-). We are even working on transactions support and, if something fails, it restores the state of the stack. > There's always been something deeply comforting about having the ASCII > patch series since it's easy to back it up and know you're in no > danger of losing everything in case of a bug. There is "stg export" which could be made to export a patch automatically at every change. > The other advantage of storing the patch stack as a an ASCII quilt > series is we have a history of changes of the patches, which we don't > necessarily have if you just use stgit to rewrite the patch. As I said in a different e-mail, we got patch history tracking in StGIT. You can even annotate specific changes. For editing, there is "stg edit [--diff]" which allows both description and patch changes. However, the StGIT approach is not fully suited for multiple developers sharing the same set of patches, especially if they are allowed to modify the same patches. For this kind of workflow, you can export the series and add the patches to a separate shared repository. StGIT has a "sync" command to synchronise changes to patches in different series (either stored as quilt series or in a different branch). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 12:50:51PM -0800, Greg KH wrote: > I can run the numbers, but almost every one of those changes has at > least 2 signed-off-by: on them, so they should all be being reviewed > properly. Good joke.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 10:16:53PM -0800, Greg KH wrote: > I was amazed at how slow stgit was when I tried it out. I use > git-quiltimport a lot and I don't think it's any slower than just using > quilt on its own. So I think that the speed issue should be the same. I like using "guilt" because I can easily reapply the patchset using "guilt push -a", which is just slightly fewer characters to type than "git-quiltimport". This also means that I don't need to switch back and forth between "git mode" and "quilt mode" when I'm editing the patches (either directly by editing the patch files, in which case afterwards I do a "guilt pop -a; guilt push -a", or by using "guilt pop", "guilt push", and "guilt refresh"). "guilt push -a" is a little bit slower than "quilt push -a", but not enough to be seriously annoying. And besides, "guilt pop -a" is slightly faster than "quilt pop -a". Using guilt is also nice because there is a bit of additional backup for previous work via the git reflogs, although to be honest I've rarely needed to use it. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 09:51:52PM +, Alan Cox wrote: > > We could simply decide that API changes affecting more than one subsystem > > Must Be Serialized(tm). Explicitly. As in "any such change is posted > > Welcome to dreamland. The only way I can get serial changes done is to > wait months and eventually simply persuade Andrew to ignore the > "maintainers" who are basically not responding. ... because we didn't realise that the pre-requisits for those patches had already gone in. If that had been the case, I'd have applied the ARM changes for the new tty ioctls immediately. It was a communication problem, not a process problem. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 11:19:14AM -0800, Greg KH wrote: > We usually get this warning today in -mm. We don't always - and I'd say in terms of ARM it would be extremely rare. The sysfs API changes at the start of the last merge window is one example of this. I had everything nicely prepared in the ARM tree for merging shortly after the window opened, and then wham bam thankyou mam, the merge window opened and a lot ended up breaking. We know that the -mm tree is pretty much useless in terms of code coverage for ARM, and it's getting increasingly unlikely that anything short of a build of all ARM defconfigs will pick up on merge issues - which is a lot of CPU cycles, and I'm not going to insist its something that should be done. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
>
> 2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
>instead have each "thing" have it's own Kconfig.foo or
>Makefile.foo that gets automatically sucked into the main
>directory Makefile or Kconfig using file globs or similar.
So we could do:
config foo
tristate "do you want foo?"
depends on USB && BAR
module
obj-$(CONFIG_FOO) += foo.o
foo-y := file1.o file2.o
help
foo will allow you to explode your PC
The [module] part would go unedited into a kbuild file
located in same dir as the Kconfig file and included by kbuild.
That would solve the Makefile issue.
And we could introduce support for
source "drivers/net/Kconfig.*"
But then we would have to make the kconfig step mandatory
for each build as we would otherwise not know if there
were added any Kconfig files.
Does this fit what you had in mind?
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Andrew Morton wrote:
> On Tue, 12 Feb 2008 16:41:49 -0800 (PST)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > Here are some odd-the-cuff
> > suggestions:
> >
> > 1) Make feature-removal-schedule a directory with files in it.
> >Everyone touches that file, creating merge issues.
> >
> > 2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
> >instead have each "thing" have it's own Kconfig.foo or
> >Makefile.foo that gets automatically sucked into the main
> >directory Makefile or Kconfig using file globs or similar.
> >
> >Even better, encode the building of things into the *.[ch]
> >files themselves, and have the Kconfig/Makefile machinery
> >automatically extract this information when you build.
>
> 3) teach people that you don't always have to add new includes right
>at the end of the list
>
> 4) teach people that you don't have to add Makefile rules right at the
>end of the list
If the list is already sorted, I insert it at the right position.
If not, well...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Greg KH wrote:
> On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote:
> > On Tue, 12 Feb 2008, Greg KH wrote:
> > > Perhaps you need to switch to using quilt. This is the main reason why
> > > I use it.
> >
> > Btw, on that note: if some quilt user can send an "annotated history file"
> > of their quilt usage, it's something that git really can do, and I'll see
> > if I can merge (or rather, coax Junio to merge) the relevant part of stgit
> > to make it possible to just basically get "quilt behaviour" for the parts
> > of a git tree that you haven't pushed out yet.
>
> Ted's description matches mine (keep quilt tree in git, edit changelog
> entries, rebase on newer kernel versions, etc.) I can go into details
> if needed.
Ack. Same for PS3 and m68k (except I don't have the m68k patches in git (yet)).
Two issues with using quilt:
1. Sometimes a patch still applies after it was integrated upstream,
2. Sometimes it's a lot of work to fixup the patches after an upstream
change. I wrote a script to do a tree-way-merge in case of a
conflict, but I haven't really tested it yet (not suitable big
conflict has happened since ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote: > > > On Tue, 12 Feb 2008, Greg KH wrote: > > > > Perhaps you need to switch to using quilt. This is the main reason why > > I use it. > > Btw, on that note: if some quilt user can send an "annotated history file" > of their quilt usage, it's something that git really can do, and I'll see > if I can merge (or rather, coax Junio to merge) the relevant part of stgit > to make it possible to just basically get "quilt behaviour" for the parts > of a git tree that you haven't pushed out yet. Ted's description matches mine (keep quilt tree in git, edit changelog entries, rebase on newer kernel versions, etc.) I can go into details if needed. > A pure patch-stack will be faster at that thing than git would be (it's > simply easier to just track patches), but on the other hand, using git > would get some other advantages outside of the integration issue (eg the > cherry-pick thing really is a proper three-way merge, not just an "apply > patch", so it can do better). I was amazed at how slow stgit was when I tried it out. I use git-quiltimport a lot and I don't think it's any slower than just using quilt on its own. So I think that the speed issue should be the same. I had a number of issues last time I tried stgit out, but maybe they are now resolved, I'll try it out tomorrow and report to the git list anything I find that doesn't work for me. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, J. Bruce Fields wrote: > > So as a result, some *random* commit that was actually fine on its own has > > now become a bug, just because it was re-written. > > If there was a "fundamental thing that didn't cause a conflict", then > the two trees in question probably didn't touch the same code, so would > probably merge cleanly, for the same reason that one rebased onto the > other cleanly. But depending on what the "fundamental thing" was, the > merge might still introduce the same bug, right? Absolutely. But if you do a true merge, the bug is clearly in the merge (automatedly clean or not), and the blame is there too. IOW, you can blame me for screwing up. Now, I will say "oh, me bad, I didn't realize how subtle the interaction was", so it's not like I'll be all that contrite, but at least it's obvious where the blame lies. In contrast, when you rebase, the same problem happens, but now a totally innocent commit is blamed just because it happened to no longer work in the location it was not tested in. The person who wrote that commit, the people who tested it and said it works, all that work is now basically worthless: the testing was done with another version, the original patch is bad, and the history and _reason_ for it being bad has been lost. And there's literally nothing left to indicate the fact that the patch and the testing _used_ to be perfectly valid. That may not sound like such a big deal, but what does that make of code review and tested-by, and the like? It just makes a mockery of trying to do a good job testing any sub-trees, when you know that eventually it will all quite possibly be pointless, and the fact that maybe the networking tree was tested exhaustively is all totally moot, because in the end the stuff that hit the main tree is something else altogether? I don't know about you, but I'd personally be really disappointed if it happened to me, and I felt that I did a really good job as a submaintainer. I'd also feel that the source control management sucked. Contrast that to the case where somebody simply does a merge error. The original work doesn't lose it's validity - so the original maintainer hasn't lost anything. And quite frankly, even the person who "screwed up" with the merge hasn't really done anything bad: these things _do_ happen. So bugs happen; not big deal. But the fact that the bugs are correctly attributed - or rather, not mis-attributed to somebody blameless - that _is_ a big deal. It's not like I will guarantee that all my manual merges are always 100% correct, much less try to guarantee that no subtle merge issue can make things not work even if it all merged totally cleanly. That isn't my point. And others will make merge mistakes too. But the people they merged from will not be blamed. So just the fact that the right commit gets blamed when somebody does a "git bisect" is I think a big issue. It's just fundamentally more fair to everybody. And it means that the people who push their work to me can really choose to stand behind it, knowing that whatever happens, their work won't get diluted by bad luck or others' incompetence. And no, maybe most people don't feel things like that matters. But I do think it's important. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Linus Torvalds wrote: > Of course, if you didn't even want to save the old branch, just skip the > first step. If you have reflogs enabled (and git does that by default in > any half-way recent version), you can always find it again, even without > having to do "git fsck --lost-found", at least as long as you don't delete > that branch, and it hasn't gotten pruned away (kept around for the next 90 > days by default, iirc) Even if you delete that branch, the "HEAD" reflog will still contain it, since it is separate from any particular branch reflog. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Linus Torvalds wrote: > So let's say that you have a remote branch that you track that goes > rebasing (let's call it "origin/pu" to match the real-life git behaviour), > then you should literally be able to do > > old=$(git rev-parse origin/pu) && > git fetch && > new=$(git rev-parse origin/pu) && > git rebase --onto $new $old > > and no, I didn't actually test it, but hey, it really should be that > simple. Or, with Git 1.5.4, just: git pull --rebase And I didn't test it yet either. Same caveats do apply. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
After glancing at some of this thread its clear to me what Stephen's real goal is: 1. collect kernel trees (or underpants) 2. ? 3. profit http://en.wikipedia.org/wiki/Underpants_Gnomes - k -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 05:20:51PM -0800, David Miller wrote: > From: Linus Torvalds <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 16:44:47 -0800 (PST) > > > gitk --merge > ... > > This is something where I actually think git could and should do better: > > git has the capability to act as more of a "quilt replacement", but > > because it wasn't part of the original design, we never actualy exposed > > the simple queue management commands to do this (stgit does things like > > that, though). > > > > So if you haven't pushed out, right now you'd have to do this stupid > > thing: > > Thanks for all the useful info. > > But as soon as I've applied any patches to my tree I've "pushed out". > So this scheme doesn't work for me. The first thing I do when I have > changes to apply is clone a tree locally and on master.kernel.org, > then I apply that first patch locally and push it out to master. > > What would be really cool is if you could do the rebase thing, push > that to a remote tree you were already pushing into and others could > pull from that and all the right things happen. > > A rebase is just a series of events, and those could propagate to > people who are pulling from the tree. I'm pretty sure GIT could > support this. git checkout -b new-tree old-tree # hack on new-tree: rebase, drop bad commits, whatever git merge -s ours old-tree git push your-public-repo new-tree:public-tree Now public-tree has a merge commit on the top with two parents, public-tree^1 and public-tree^2. public-tree^1 is the tip of the new cleaned-up history, and public-tree^2 points to the old stuff. I sometimes use that privately as a way to keep track of the history of a patch-series, but I assume Linus would shoot anyone that tried to submit such a monstrosity upstream --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 05:31:10PM -0800, Linus Torvalds wrote: > The importance of merging (rather, not screwing up history in general) > becomes really obvious when things go tits-up. Then they go tits-up > *without* screwing up the history of the trees that were hopefully tested > individually. > > If you re-base things that others developed, you lose that. Imagine if I > merged first Greg's tree (by rebasing), and then there was some > fundamental thing that didn't cause a conflict, but just made something > not work, when I rebased yours on top. Think about what happens. > > Now I've merged (say) 1500 networking-related commits by rebasing, but > because I rebased on top of Greg's tree that I had also rebased, > absolutely *none* of that has been tested in any shape of form. I'd not > use most of the things I pulled, so I'd never see it, I'd just push out > something that was very different from *both* trees I pulled, with no way > to really blame the merge - because it doesn't even exist. > > So as a result, some *random* commit that was actually fine on its own has > now become a bug, just because it was re-written. If there was a "fundamental thing that didn't cause a conflict", then the two trees in question probably didn't touch the same code, so would probably merge cleanly, for the same reason that one rebased onto the other cleanly. But depending on what the "fundamental thing" was, the merge might still introduce the same bug, right? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 09:00:16PM -0600, James Bottomley wrote: > On Tue, 2008-02-12 at 18:35 -0800, Linus Torvalds wrote: > > > > On Tue, 12 Feb 2008, James Bottomley wrote: > > > > > > Yes, this is exactly the feature I'm looking for. It would allow the > > > downstream users of a rebased tree to rebase themselves correctly. > > > > > > All the information about the rebase is in the reflog ... it can't be > > > too difficult to pass it through on a pull and allow the downstream tree > > > to do the right thing. > > > > Guys, you simply have no idea what you're talking about. > > > > Those downstream trees can have done things themselves. They *depended* on > > the state you gave them. > > > > You can't just say "oops, I lied, this is the state you should have used, > > now it's _your_ mess to sort out". > > > > OF COURSE it's what you'd like to use - it absolves you of any and all > > actual responsibility. But dammit, that's not what anybody else wants than > > the irresponsible person who cannot be bothered to stand up for his work! > > > > If you're not confident enough about your work, don't push it out! It's > > that simple. Pushing out to a public branch is a small "release". > > > > Have the f*cking back-bone to be able to stand behind what you did! > > Erm, I would like this feature as a downstream user. > > I'm not asking for this to be the default or even easily available. > However, when you know you've based a downstream tree on what you know > to be a volatile base, it would be very useful information to have. > > Right at the moment, I maintain a and a -base and > simply cherry pick the commits between the two to do the right thing > when I know my volatile base has changed. It would be very helpful to > have a version of rebase that new my base had been rebased. > > Basing on a tree I know to be volatile is sometimes a development > decision I make as a downstream user ... I'm just wishing the tools > could help me handle the problems better. > There's also a difference between a downstream user and a downstream developer. While rebasing does cause trouble for folks doing downstream development off of the tree in question, there's no reason why this should be the case for users that are simply trying to follow the tree. I push changes out to my tree so people have a chance to poke through it and to see what's going on, though I do not generally encourage people to fork off of it given that I end up rebasing periodically. At the moment the options seem to be down to the following: 1 - Push changes out without rebasing 2 - Push changes out periodically rebased 3 - Hide the tree away in my home directory on hera 4 - Force people to get at the current tree through -mm 4) generally isn't very realistic, given that -mm releases have far too many other changes and the releases are quite spread out. 3) is doable, but I publish the tree as a convenience to the folks wanting to see what's going on in the tree, and I would rather continue doing so. This leaves 2) my current workflow, and 1) which ends up creating a lot of extra metadata. The common cases thelre are patches + reversions and merge points. Holding on to a patch for some period of time before pushing it out to ensure that there won't be a reversion later rarely tends to work in practice. Most of the time I end up having to revert something it's because someone else found a problem with a given change _after_ the it was pushed out, and which was not caught with my local tree or testing. On the other hand, perhaps it's also useful to see the reversions in the history, particularly to see what the rationale for the change not working out was (which could be helpful for people working on the same stuff later on). This then leaves merge points. During merge window time people are pulling on a pretty frequent basis, which also breaks down to a few fairly common cases: 1 - Bringing in new stuff to be supported (ie, system calls). 2 - Infrastructure support bits that have gone in through a subsystem tree, when you have local patches blocked until the subsystem tree has merge. 3 - Catching and resolving conflicts before bisect gets broken. 4 - Trying to make sure that it all merges cleanly. I've generally worked around 2) by doing multiple merges during the merge window, but it's also appealing to just rebase and throw in the rest of the outstanding bits before sending out the initial merge request. 1) and 3) often tend to have dependencies on each other, and tend to be the area where the most troubles arise. 3) and 4) are really the places where rebasing appeals the most, and is also where we see the highest concentration of merge points. If there's a nice way to resolve this without a rebase that would be nice. For users in general, I suspect most people are just interested in a pull that can traverse a rebase without having
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 19:31 -0800, Linus Torvalds wrote: > > On Tue, 12 Feb 2008, James Bottomley wrote: > > > > Right at the moment, I maintain a and a -base and > > simply cherry pick the commits between the two to do the right thing > > when I know my volatile base has changed. It would be very helpful to > > have a version of rebase that new my base had been rebased. > > Hey, I know, you could use.. drumroll.. > > "git rebase" > > I know that's a big leap of faith, to use git rebase for rebasing, but > there you have it. Us git people are kind of odd that way. > > IOW, if you know the old broken base, and the new base, just do > > git rebase --onto newbase oldbase > > and it should do exactly that (basically lots of automated cherry-picks). OK, smarty-pants ... that works nicely, thanks! I'm used to maintaining and -base, so this probably suits my workflow better than getting the information from the reflog. It wasn't clear from the git rebase man page that it would work like that. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Linus Torvalds wrote: > > git rebase --onto $new $old ..and in case it wasn't clear - this is just a general way of saying "move the commits on this branch since $old to be based on top of $new" instead. You can pick out those old/new commit ID's using gitk or whatever if you wish. Neither the $new or the $old needs to even be an existing branch - just pick them with gitk. So if you literally want to just move the top 5 commits (assuming those top five cmmits are just a nice linear thing you did) from the current branch to be on top on another branch instead, you can literally do this: # save this state, maybe we want to keep it around. Call it "old" git branch old-branch # rebase the top five commits onto $target git rebase --onto $target HEAD~5 ta-daa - all done. The branch you are on will now have been rewritten to be the top five commits moved to be on top of the $target you chose, and if you want to get back the old state, it's nicely squirrelled away in "old-branch". (That obviously assumes no merge conflicts - you'll have to resolve those yourself ;) Of course, if you didn't even want to save the old branch, just skip the first step. If you have reflogs enabled (and git does that by default in any half-way recent version), you can always find it again, even without having to do "git fsck --lost-found", at least as long as you don't delete that branch, and it hasn't gotten pruned away (kept around for the next 90 days by default, iirc) Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, James Bottomley wrote: > > Right at the moment, I maintain a and a -base and > simply cherry pick the commits between the two to do the right thing > when I know my volatile base has changed. It would be very helpful to > have a version of rebase that new my base had been rebased. Hey, I know, you could use.. drumroll.. "git rebase" I know that's a big leap of faith, to use git rebase for rebasing, but there you have it. Us git people are kind of odd that way. IOW, if you know the old broken base, and the new base, just do git rebase --onto newbase oldbase and it should do exactly that (basically lots of automated cherry-picks). [ But the fact is, if you did anything fancy (like pulled in other peoples work), you cannot sanely rebase _those_ peoples work. They didn't screw up to begin with! You can play with "git rebase -i --preserve-merges", of course, but I really think you're doing something wrong if you start pulling other peoples work into an unstable thing, so while it may work, I'd strongly suggest against even trying, because the problem is your workflow ] So let's say that you have a remote branch that you track that goes rebasing (let's call it "origin/pu" to match the real-life git behaviour), then you should literally be able to do old=$(git rev-parse origin/pu) && git fetch && new=$(git rev-parse origin/pu) && git rebase --onto $new $old and no, I didn't actually test it, but hey, it really should be that simple. [ And no, you don't really need to do those "old=" and "new=" things, they are there to make it explicit - you could easily just have done git fetch .. oh, noticed that origin/pu changed .. git rebase --onto origin/pu origin/[EMAIL PROTECTED] where we just let git take care of the old/new itself using the reflog, so that "origin/[EMAIL PROTECTED]" assumes that you just know that the only thing that has changed origin/pu was that previous "git fetch", and that really *did* change it. ] In other words, git does give you exactly what you want, but nothing really changes the fact that you should only rebase like this only if: - you haven't already exported the result (or only exported it as those unstables branches that people know to avoid) - your changes on top are just your own linear series of commits (where "applying a patch from somebody else" is still _your_ commit, of course, just with authorship attributed to somebody else) so that part really is very fundamental. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 18:35 -0800, Linus Torvalds wrote: > > On Tue, 12 Feb 2008, James Bottomley wrote: > > > > Yes, this is exactly the feature I'm looking for. It would allow the > > downstream users of a rebased tree to rebase themselves correctly. > > > > All the information about the rebase is in the reflog ... it can't be > > too difficult to pass it through on a pull and allow the downstream tree > > to do the right thing. > > Guys, you simply have no idea what you're talking about. > > Those downstream trees can have done things themselves. They *depended* on > the state you gave them. > > You can't just say "oops, I lied, this is the state you should have used, > now it's _your_ mess to sort out". > > OF COURSE it's what you'd like to use - it absolves you of any and all > actual responsibility. But dammit, that's not what anybody else wants than > the irresponsible person who cannot be bothered to stand up for his work! > > If you're not confident enough about your work, don't push it out! It's > that simple. Pushing out to a public branch is a small "release". > > Have the f*cking back-bone to be able to stand behind what you did! Erm, I would like this feature as a downstream user. I'm not asking for this to be the default or even easily available. However, when you know you've based a downstream tree on what you know to be a volatile base, it would be very useful information to have. Right at the moment, I maintain a and a -base and simply cherry pick the commits between the two to do the right thing when I know my volatile base has changed. It would be very helpful to have a version of rebase that new my base had been rebased. Basing on a tree I know to be volatile is sometimes a development decision I make as a downstream user ... I'm just wishing the tools could help me handle the problems better. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 06:20:12PM -0800, David Miller wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 18:06:13 -0800 > > > So perhaps a better workflow would be keep the linux-next trees all > > messy, and then each developer can consolidate, rebase, join and > > drop things prior to sending their individual trees to Linus. > > We could do that, but I believe Linus's main point is that if we go > and change the trees then in the end we're merging in something > different than what was actually tested, namely all the original trees > as merged into linux-next. > > And I kind of agree with that. Make the distinction earlier. With ocfs2 and configfs (we got this scheme from Jeff), we keep the topic branches as "unsafe" - that is, officially rebaseable . We merge them all into a big "ALL" branch, which is also "unsafe". Andrew pulls this for -mm, and it gets tested here. If there is a brown-paper-bag problem, we can tell the original author to fix it. Then we re-pull the topic - effectively a rebase. The ALL is also rebased. But that's Ok, it will never go towards Linus. When a topic is considered worthy of going upstream, we pull it to a branch called "upstream-linus". This branch is *NEVER* rebased. Now that the topic is in upstream-linus, the original topic branch can't be rebased either. So any fixes to that topic going forward will stay in the history. Since that topic was pulled into ALL for testing, we are using the identical commits that got tested. Joel -- "I have never let my schooling interfere with my education." - Mark Twain Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, James Bottomley wrote: > > Yes, this is exactly the feature I'm looking for. It would allow the > downstream users of a rebased tree to rebase themselves correctly. > > All the information about the rebase is in the reflog ... it can't be > too difficult to pass it through on a pull and allow the downstream tree > to do the right thing. Guys, you simply have no idea what you're talking about. Those downstream trees can have done things themselves. They *depended* on the state you gave them. You can't just say "oops, I lied, this is the state you should have used, now it's _your_ mess to sort out". OF COURSE it's what you'd like to use - it absolves you of any and all actual responsibility. But dammit, that's not what anybody else wants than the irresponsible person who cannot be bothered to stand up for his work! If you're not confident enough about your work, don't push it out! It's that simple. Pushing out to a public branch is a small "release". Have the f*cking back-bone to be able to stand behind what you did! Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 17:20 -0800, David Miller wrote: > What would be really cool is if you could do the rebase thing, push > that to a remote tree you were already pushing into and others could > pull from that and all the right things happen. > > A rebase is just a series of events, and those could propagate to > people who are pulling from the tree. I'm pretty sure GIT could > support this. Yes, this is exactly the feature I'm looking for. It would allow the downstream users of a rebased tree to rebase themselves correctly. All the information about the rebase is in the reflog ... it can't be too difficult to pass it through on a pull and allow the downstream tree to do the right thing. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 18:06:13 -0800 > So perhaps a better workflow would be keep the linux-next trees all > messy, and then each developer can consolidate, rebase, join and > drop things prior to sending their individual trees to Linus. We could do that, but I believe Linus's main point is that if we go and change the trees then in the end we're merging in something different than what was actually tested, namely all the original trees as merged into linux-next. And I kind of agree with that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Andrew Morton wrote: > > So it would not be efficient for David to do all this queue-cleaning > *prior* to putting the tree into linux-next, because more stuff will pop up > anyway. Well, what others have done is to have special "temporary branches". This is what git itself does, for example. The "pu" branch in git is used for experimental stuff, and it's _declared_ to be rebased, redone, and generally just unsafe at any moment. So it is easy to have a special "testing" branch that is just declared to be unsafe. Make Linux-next pull that testing branch - it will pollute the Linux-next tree (and anybody else who just wants to see what the current state is), but since those are re-generatd from scratch every day _anyway_, so who cares? But don't make it something people pull by mistake (ie never call it "master", and when mentioning it in some email message, always mention the fact that it's not a stable branch, and never ask anybody to pull it without making it very clear that it's just for testing, not for real merging). So git does have support for those things. They are very much "secondary" branches (any tree they are pulled into will itself become "poisoned" and unstable), but it's easy enough to have something like that for testing purposes. And if it all tests out fine, you can just move it as-is into the "real" branch if you want to. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote: > On Tue, 12 Feb 2008, Greg KH wrote: > > > > Perhaps you need to switch to using quilt. This is the main reason why > > I use it. > > Btw, on that note: if some quilt user can send an "annotated history file" > of their quilt usage, it's something that git really can do, and I'll see > if I can merge (or rather, coax Junio to merge) the relevant part of stgit > to make it possible to just basically get "quilt behaviour" for the parts > of a git tree that you haven't pushed out yet. So this is what I do for ext4 development. We maintain a quilt series in git, which is located here at: http://repo.or.cz/w/ext4-patch-queue.git A number of ext4 developers have write access to commit into that tree, and we coordinate amongst ourselves and on [EMAIL PROTECTED] I tend to suck it into git using the "guilt" package, and do periodic merge testing with a number of git queues to detect potential merge conflicts. Not as many as James does, but I may start doing more of that once I steal his scripts. :-) The patch queue also gets automatic testing on a number different platforms; for that reason the series files comments which version of the kernel it was last based off of, so the ABAT system can know what version of the kernel to use as the base of the quilt series. I do a fair amount of QA, including copy editing and in some cases rewriting the patch descriptions (which are often pretty vile, due to a number of the ext4 developers not being native English speakers; not their fault, but more than once I've had no idea what the patch description is trying to say until I read through the patch very closely, which is also good for me to do from a code QA point of view :-). Periodically, the patch queue gets pushed into the ext4.git tree and as a patch series on ftp.kernel.org. I've never been very happy with stgit because of past experiences which has scarred me when it got get confused and lost my entire patch series (this was before git reflogs, so recovery was interesting). There's always been something deeply comforting about having the ASCII patch series since it's easy to back it up and know you're in no danger of losing everything in case of a bug. Also, having the patch series stored in ASCII as a quilt stack means that we can store the quilt stack itself in git, and with repo.or.cz it allows us to have multiple write access to the shared quilt stack, while still giving us the off-line access advantages of git. (Yes, I've spent plane rides rewriting patch descriptions. :-) The other advantage of storing the patch stack as a an ASCII quilt series is we have a history of changes of the patches, which we don't necessarily have if you just use stgit to rewrite the patch. So we have the best of both worlds; what gets checked into Linus's tree is a clean patch series, but we keep some history of different versions of a patch over time in the ext4-patch-queue git repository. (I wish we had better changelog comments there too, but I'll take what I can get.) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 17:57:19 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> wrote: > - and you actually can help fix your issues by doing some simple things >*before* pushing out, rather than push out immediately. IOW, do your >whitespace sanity fixes, your compile checks etc early, and don't push >out until after you've done them. > One of the things which linux-next could/should do is to help weed out the silly build breaks, typos, missing documentation updates, missed checkpatch opportunities, etc, etc. As well as real bugs. So it would not be efficient for David to do all this queue-cleaning *prior* to putting the tree into linux-next, because more stuff will pop up anyway. So perhaps a better workflow would be keep the linux-next trees all messy, and then each developer can consolidate, rebase, join and drop things prior to sending their individual trees to Linus. If so, then git could perhaps help, by retaining sufficient metadata for the maintainer to track the fact that this-patch-here fixes that-patch-there. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, David Miller wrote: > > Now how do I remove a bogus commit for a tree that I've already pushed > out and published for other people, without any record of it appearing > in the GIT tree any more? So, the answer is: if others have actually pulled, it's simply not possible. There simply is no way to undo history that isn't local any more. You just *have* to revert, or you need to find every single person that pulled (directly or indirectly) and ask them to undo all the work they did on top of your bad commit. This is not git-related, btw. That's just how the world works. It's a bit like the internet - if you said something stupid on #IRC and it made it to bash.org, there's not a whole lot you can do to "undo" your stupidity. You can only hope to do better in the future and assume people forget. > How do I insert build fixes into existing changesets so that the tree > is more bisectable? Just delay pushing out. There really is _zero_ downside to this. None at all. There are only upsides. > If Jeff merged in a tree that introduced a ton of whitespace errors > git is complaing about, is there a way I can fixup that changeset > in-place? (or should I tell Jeff to start adhering to GIT's whitespace > warning messages when he applies patches?) Umm. Git doesn't complain about whitespace _except_ when applying patches. So if you don't rebase his work, you'll never see the whitespace warnings either! Of course, we'd probably wish that Jeff cared about the whitespace warnings and pushed back on them, but the fact is, that warning isn't meant for you - because by the time you pull Jeff's tree, it's simply not your issue any more. Jeff already applied it. Either he's your trusted lietenant or he's not. Quite frankly, to me it sounds like you're not ready to "let go" and trust the people under you. Trust me, it's worth it. It's why your life is easy: I have let go and I trust you. Also, I'd *much* rather have a few problems in the tree than have people screw up history in order to hide them. Sure, we want to keep things bisectable, but quite frankly, if you do a reasonable job and compile the kernel before you push out, it will be "mostly bisectable". And yes, mistakes happen. Mistakes will *always* happen. It's ok. Relax. Let me put it another way: You're _both_ going to be *much* better off pushing back on Jeff, telling him that "I can't pull from you because your tree is ugly and doesn't compile", than taking his tree and rebasing it. Remember? I used to do that all the time. I berated the ACPI people for creating monster trees that were horrible and contained fifteen merges and two real commits. I didn't try to clean it up for them, I just told them what the problem was, and you know what? The ACPI tree is one of the cleanest ones out there now! So in short: - clean trees and bisectability are all wonderful things. No doubt about that at all. - but if getting there means that you lose a lot of _other_ wonderful things (like being able to trust history, and the people being under your watchful eyes havign to deal with you re-writing their trees), we'd be much better off taking the occasional commit that fixes things up _after_ the fact rather than before! - and you actually can help fix your issues by doing some simple things *before* pushing out, rather than push out immediately. IOW, do your whitespace sanity fixes, your compile checks etc early, and don't push out until after you've done them. Hmm? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 17:16:03 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 16:37:42 -0800 > > > Well there's a case in point. rcupdate.h is not a part of networking, and > > it is random tree-wandering like this which causes me problems and which > > will cause Stephen problems. > > > > Now, I don't know which tree "owns" rcupdate.h but it ain't networking. > > Probably git-sched. > > > > Nothing in networking depends upon that change (which has a typo in the > > comment, btw) hence it can and should have gone through > > whichever-tree-owns-that-file. > > > > For Stephen's sake: please. > > At least thie time I did make sure that change got posted to > linux-kernel and got properly reviewed by the de-facto maintainer > (Paul McKenney). :-) Ah, thanks for that - I'm behind in my lkml reading. Again. > I'll toss it. While I was there I spotted a howling bug in rcu_assign_pointer(): a double-touch of the second arg. Nobody has done rcu_assign_pointer(p, something_with_side_effects); before? That would be surpising... Paul has been informed ;) > But how do I do that using GIT without rebasing and without > having this ugly changeset and revert in there? Who, me? umm, get git changed? It seems pretty clear that it isn't matching legitimate kernel development workflow. And it is a tool's job to do that, rather than forcing humans to change there practices. > That's the thing I want answered, and although Al claims it does, > git cherry-pick does not seem to do what I want either. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 17:41:19 -0800 (PST) > Trust me, you don't know how good you have it. I know, preserving history is valuable. I'll take up the various suggestions and try working a little differently this time around. We'll see how well it works. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, David Miller wrote: > > But as soon as I've applied any patches to my tree I've "pushed out". > So this scheme doesn't work for me. The first thing I do when I have > changes to apply is clone a tree locally and on master.kernel.org, > then I apply that first patch locally and push it out to master. I actually suggest you literally delay your push-out. I don't generally delay things by a lot, but I tend to try to at least do a compile in between pushing out - and even if I've pulled something in between the thing that broke, I'll just "git reset --hard" to a working state if something broke, and just re-pull instead of even trying to rebase or anything like that. (IOW, I often find it much easier to just start over and re-do than actually doing a rebase). I don't do it all the time, by any means, but there's really no huge reason to push out all the time. And that's doubly true for subsystem maintainers. Quite often, the right thing to do is to only push out when you are ready to do the "please pull" message. > What would be really cool is if you could do the rebase thing, push > that to a remote tree you were already pushing into and others could > pull from that and all the right things happen. It would also be really cool if Claudia Schiffer had decided that hiding under my desk is a good idea. IOW, you really haven't though that through. That is how TLA and darcs worked, and it's a total disaster. Trust me, you don't know how good you have it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 17:31:10 -0800 (PST) > You don't see the problems as much, because you merge probably only > about a tenth of the volume I merge, and you can keep track of the > subsystem more. Good point. Now how do I remove a bogus commit for a tree that I've already pushed out and published for other people, without any record of it appearing in the GIT tree any more? How do I insert build fixes into existing changesets so that the tree is more bisectable? If Jeff merged in a tree that introduced a ton of whitespace errors git is complaing about, is there a way I can fixup that changeset in-place? (or should I tell Jeff to start adhering to GIT's whitespace warning messages when he applies patches?) Those are basically the major operations that would allow me to seriously consider rebasing a ton less often. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, David Miller wrote: > > > Put another way: think of the absolute *chaos* that would happen if I were > > to rebase instead of just merging. Every time I pull from you I'd > > invalidate your whole tree, and you'd have to re-generate. It gets > > unmaintainable very quickly. > > I actually wouldn't mind that, the first thing I do when sending a > pull request is I stop putting things into my tree and as soon as the > recipient pulls I wipe out my tree and clone a fresh copy of their's. You *really* don't see the problem here? > I really like that mode of operation. *YOU* like it, because it never generates any issues for *you*. You're the top in your heap, and the people above you don't do that insane thing, so you get all of the advantages, with none of the downsides. Of *course* you like it. But as people have pointed out, it generates issues for the people under you! If I did it, the people who now complain about networking would not just be a couple, it would be everybody. Nobody could depend on anything out there, because everything would have to rebase. You just don't see the problems, because the only person above you isn't crazy enough to do what you propose. You also don't do ten merges a day of subsystems you don't know. The importance of merging (rather, not screwing up history in general) becomes really obvious when things go tits-up. Then they go tits-up *without* screwing up the history of the trees that were hopefully tested individually. If you re-base things that others developed, you lose that. Imagine if I merged first Greg's tree (by rebasing), and then there was some fundamental thing that didn't cause a conflict, but just made something not work, when I rebased yours on top. Think about what happens. Now I've merged (say) 1500 networking-related commits by rebasing, but because I rebased on top of Greg's tree that I had also rebased, absolutely *none* of that has been tested in any shape of form. I'd not use most of the things I pulled, so I'd never see it, I'd just push out something that was very different from *both* trees I pulled, with no way to really blame the merge - because it doesn't even exist. So as a result, some *random* commit that was actually fine on its own has now become a bug, just because it was re-written. You don't see the problem here? Yes, this is the *crap* you do all the time. You don't see the problems as much, because you merge probably only about a tenth of the volume I merge, and you can keep track of the subsystem more. But even though you don't have nearly the same kinds of problems, people have complained about your process. So there's a real reason why we strive to *not* rewrite history. Rewriting history silently turns tested code into totally untested code, with absolutely no indication left to say that it now is untested. You can limit the damage by keeping it to a single subsystem and by serializing that subsystem by - for example - talking it over amonst yourself what order you do things in, and yes, most of the time rewriting doesn't hurt anything at all, but I guarantee you that it's a big mistake to do, and the mistake gets bigger the more _independent_ people you have involved. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 04:59:23PM -0800, Linus Torvalds wrote: > > > On Wed, 13 Feb 2008, Al Viro wrote: > > > On Tue, Feb 12, 2008 at 07:16:50PM -0500, J. Bruce Fields wrote: > > > > Ahem... Use of git-cherry-pick preserves commit information just fine. > > > > > > Not by default, at least (note they said "commiters", not "authors"): > > > > That's why you give it -r. > > Hmm. "-r" is a no-op to git-cherry-pick. *duh* OK, I plead the lack of caffeine when reading the original posting. -r used to be "reproduce the changeset", but that _excludes_ committer. Nevermind. FWIW, I prefer to keep many branches and use suffix (.b) to distinguish between them. And cherry-pick/reorder/split/collapse as needed on transition to the next one. At least that avoids some problems for secondary trees - branches do not jump. Since branches tend to be relatively small, they don't get conflicts that open and I can postpone switch to new branch until it really has to be done. I don't know how to deal with tricky branch topology; every time when I get to structure like it becomes very painful to work on all these topics in parallel. For trees maintained by different people... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:53:50 -0800 (PST) > The fact is, that "outlying code" is where we have all the bulk of the > code, and it's also where we have all those developers who aren't on the > "inside track". So we should help the outliers, not the core code. Good point. For the record I write drivers that use infrastructure too and have to deal with the API changes just as equally :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:49:46 -0800 (PST) > Btw, on that note: if some quilt user can send an "annotated history file" > of their quilt usage, it's something that git really can do, and I'll see > if I can merge (or rather, coax Junio to merge) the relevant part of stgit > to make it possible to just basically get "quilt behaviour" for the parts > of a git tree that you haven't pushed out yet. Sounds interesting and nice, but not relevant for my current workflow. I've always "already pushed out". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:47:26 -0800 > My usual way of fixing these things when they pop up is to just move > the offending addition to some random position other than > end-of-list. I must have done this hundreds of times and as yet I > don't think anyone has noticed ;) That sounds like a real useful usage of your time. I think my proposal saves everyone, including you, this time and the effort necessary to implement it would only need to be expended once instead of this ever present time and learning sink you seem to be advocating. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 12:02:08 +1100 Stephen Rothwell wrote: > Hi all, > > Andrew was looking for someone to run a linux-next tree that just > contained the subsystem git and quilt trees for 2.6.x+1 and I (in a > moment of madness) volunteered. So, this is to announce the creating of > such a tree (it doesn't exist yet) which will require some (hopefully) > small amount of work on the part of subsystem maintainers. > > Those interested in discussion about this are encouraged to join the > [EMAIL PROTECTED] mailing list. > > The first things I need from the subsystem maintainers (you know who you > are) are a contact address (a list address is fine) and at least one git > branch or quilt series that contains all the things you want to see go > into 2.6.26. I am happy for there to be multiple branches/series (in > fact there probably will need to be in some cases where there are > dependencies on others work). Hi Stephen, Please merge the quilt series/patchset from http://oss.oracle.com/~rdunlap/kernel-doc-patches/current/ I expect this to be fairly small and localized (very few conflicts). Thanks, --- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:44:47 -0800 (PST) > gitk --merge ... > This is something where I actually think git could and should do better: > git has the capability to act as more of a "quilt replacement", but > because it wasn't part of the original design, we never actualy exposed > the simple queue management commands to do this (stgit does things like > that, though). > > So if you haven't pushed out, right now you'd have to do this stupid > thing: Thanks for all the useful info. But as soon as I've applied any patches to my tree I've "pushed out". So this scheme doesn't work for me. The first thing I do when I have changes to apply is clone a tree locally and on master.kernel.org, then I apply that first patch locally and push it out to master. What would be really cool is if you could do the rebase thing, push that to a remote tree you were already pushing into and others could pull from that and all the right things happen. A rebase is just a series of events, and those could propagate to people who are pulling from the tree. I'm pretty sure GIT could support this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:37:42 -0800 > Well there's a case in point. rcupdate.h is not a part of networking, and > it is random tree-wandering like this which causes me problems and which > will cause Stephen problems. > > Now, I don't know which tree "owns" rcupdate.h but it ain't networking. > Probably git-sched. > > Nothing in networking depends upon that change (which has a typo in the > comment, btw) hence it can and should have gone through > whichever-tree-owns-that-file. > > For Stephen's sake: please. At least thie time I did make sure that change got posted to linux-kernel and got properly reviewed by the de-facto maintainer (Paul McKenney). :-) I'll toss it. But how do I do that using GIT without rebasing and without having this ugly changeset and revert in there? That's the thing I want answered, and although Al claims it does, git cherry-pick does not seem to do what I want either. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
