* Paul Mackerras <paulus@xxxxxxxxx> wrote: > > I actually start regretting that i do rebases too frequently - > > some people (not you really, but you gave me the perfect example > > to reply to) want more and seem to think they are _entitled_ to > > rebases and are entitled to backmerges. The thing is, rebases > > are not free. They are risky and error-prone, and they destroy > > Git history. > > To be honest, I didn't think I was asking for a rebase of > something which was already cast in stone, since I didn't think > you would have cast a commit in stone before doing a build test on > powerpc. I think there's a fundamental disconnect with reality here. The thing is, as the maintainer of certain core kernel subsystems i _have to_ mirror and honor the system usage and hardware preferences of developers, testers and users. Those are predominantly x86 based currently. I cross-test to a lot of architectures because i'm nice but in practice it rarely matters. (It goes beyond that btw: i try to test more common drivers within x86 too, etc.) If you want to change that reality you can do it the old fashioned, fair way: build cool hardware, send more SDVs to kernel developers, make PowerPC more widely used, etc. If i put more effort into testing what nobody uses i'd be doing a disservice to Linux - i'd disproportionately favor PowerPC just because you are a squeakier wheel. I.e. please _earn_ your usage share, dont try to dicate it artificially ... It does not work the other way, you cannot force in the kernel space what PowerPC did not manage to achieve in the marketplace. If you suggest that each and every subsystem maintainer who touches code that can be built on non-x86 architectures has to cross-build to 20+ architectures to be able to push out a tree, all the time, and has to rebase if this ever gets omitted, you are really defying reality and are hurting Linux. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|