> Jeffrey Hundstad writes:
> - ->This updates the location and current versions for
> - ->linux/Documentation/Changes relative to linux-2.1.125:
> - ->
> - ->begin 644 Changes-update-from-2.1.125.diff.gz
> - ->M'XL(")-5(38"`T-H86YG97,M=7!D871E+69R;VTM,BXQ+C$R-2YD:69F`*V5
>
> I don't think it was good idea to uudecode such small file.
>
>
> I'm also not sure if those changes make sense. The list in the
> 'Changes' files is not supposed to list the Latest-N-Greatest
> but minimal revision which is working with kernel. It is at least
> how I see it.
Correct; I try to list the minimum functional version that's available, not
necessarily the latest and greatest. That's not to denigrate your effort,
Jeffrey. Some of that is stuff that needs to be updated.
However, it was a bad idea for a different reason. The Changes file is
reasonably maintained, so it's a good idea to send patches to the maintainer
instead of straight to Linus / linux-kernel. Some of those patches (the
relevant stuff, like the procps update, for example), are included in the
patch I sent Linus last Friday. Now, he gets to wade through three
conflicting patches for that file before he releases 2.1.126--one from me
and two from Jeffrey. Odds are, he'll just reject all three as a result,
and I don't blame him.
People, the maintainers are there for a reason. In this case, it's fairly
trivial to identify the overlap, and it's not all that important to get
correct / included anyway (code's always more important than documentation,
IMHO), but it's a case in point for everyone who's been griping about the
alleged breakdown in Linus' I/O scaling to consider. In this case, if those
patches had come to me, I would've sorted out the overlap and Linus would've
gotten one clean patch that he could've applied thoughtlessly. As it is, he
get three patches, will probably reject all three, and will then get a
fourth sorted-out patch from me in a few more days that he'll actually
apply. That's a lot of work for him that could've been avoided.
later,
chris
--
Chris Ricker kaboom@gatech.edu
chris.ricker@m.cc.utah.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/