> One "patch penguin" scales no better than I do. In fact, I will claim
> that most of them scale a whole lot worse.
Oh, one other thing. I didn't emphasize the possibility that the patch
penguin might eventually run a public CVS tree that the various subsystem
maintainers might be granted commit access to, because I didn't want to
confuse the issue.
You don't use CVS, this proposal is not asking you to use CVS, and you seem
to dislike other people using CVS. I'm under the impression this is because
CVS blurs together the patches you then need to receive and code review to do
your job as architect of the Linux kernel.
It takes a skilled human being to extract clean patches from a CVS tree and
feed them on to you in the format you prefer: one per email, plain text, with
a description at the top. Clean, atomic patches that do exactly one thing,
and don't have any cross-reference dependencies on any other pending patches
in the patch set. No automated CVS-like tool will ever be able to do that
AND resolve conflicts between patches. You need a human.
Extracting patches out of a CVS tree and hand-massaging them into a format
you would accept would be a big part of the integration maintainer's job.
If they chose to run a CVS tree. (Backing the patches out if you rejected
the whole idea of that particular patch would be a lot of work too, but it
would also be part of the integration maintainer's job.)
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/