On Wed, 2007-01-24 at 13:23 -0800, john stultz wrote:
> Well, I suggested the kernel/time/timekeeping.c change go in last cycle,
> when you pushed your other cleanups, because that sort of large,
> move-tons-of-code patch sucks to keep out of the tree for long as it
> would surely collide with something at some point.
It wasn't too bad (I submitted it to -mm day before yesterday) two
collision one from the vsyscalls change, and another in the
CONFIG_TIME_INTERPOLATION .
Do you know of any others?
> Nonetheless, code talks, so don't let me get in the way, but I really
> think patching on top of the HRT queue is the best way forward.
True, you might want to ACK my kernel/time/timekeeping.c patch (as a
reminder).
> Even if they revert portions, it clearly points out why your changes
> would be better, focusing the discussion, instead of just making a large
> alternate patch queue.
That hurts tho .. Cause if HRT just goes in the maintainers will assume
it's solid, plus the proponents of the code become defacto reviewers ..
So it make it an up hill battle the whole way .
Daniel
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
