> I got a bit tired of trying to be proactive. The last time was for the > %gs per cpu thing, which I saw coming. The basic problem is that > there's no well organised git tree I can pull from and bisect to trace > problems. There is a quilt tree as documented in MAINTAINERS ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/ It is fully bisectable (relative to ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/BASEKERNEL) and everything. It is also possible to generate git trees from this using some simple scripts if you really need git for something (I do this for my merges to Linus). But the reason -- similar to Andrew -- i don't keep a continuous git mirror of the quilt tree is that patch ordering etc. might change anytime and it is hard to express that in a continuous git tree. Instead I just generate the git branches on demand from some fixed state for merging. > My strategy now is to wait for the merge window to close and then go > around sweeping up the mess and yelling at the offenders ... it's what > all the non-x86 architectures do, and it's definitely an easier process. Fine too. Since you're effectively the only Voyager user anyways that's a great model. -Andi _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
