> > Pick up the fix from the list, its a couple of weeks old
>
> Bludgeon me blue Alan, but that's a pretty sad configuration management
> system.
I disagree. It's fast, portable, has no overhead for the common case.
Looks like a perfect system to me :)
> The problem in sock.h is easy enough to see, but there's no record of
> who made _any_ changes, let alone the change which broke it.
What makes you think that some form of "configuration management system"
is better than asking this list?
> No indication of when the changes occurred.
Sometime between 2.2.1 and 2.2.2. If you're not prepared to hack around
to find and fix the problem, you probably shouldn't be aware of
> No indication of which kernel versions they were in.
I have to argue here - code repositories with full revision histories make
the issue of "kernel versions" somewhere between vague and irrelevant.
> No process for backing out the changes, no process for locating new
> changes, and all that good stuff.
Of course there's a process for backing out the changes:
$ gunzip patch-2.2.2.gz
$ vim patch-2.2.2
/^diff.*filter
v/^diff
k$dZZ
is a hell of a lot easier than learning how to work this month's
favourite code repository.
> I appreciate that the developers appear to be comfortable with this
> state of affairs, although I can't for the life of me understand why
> :-).
Because developer time is more important than user time? Some people
like CVS, Linus has said that he would look at Bitkeeper. Not that my
opinion matters, but I like "cp -a" and "diff" to track my hacks.
> For the sake of the _users_ of the developers' efforts: Roll on
> BitKeeper!
Perhaps Linux 2.2 isn't for you yet if you're not prepared to put in
some effort to run it.
Matthew.
-
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/