Re: [tip:timers/core] timekeeping: Increase granularity ofread_persistent_clock()

[Ingo Molnar]

* 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/