Here, I think, is the difference. You're thinking in terms of patches as
the "base unit"; I'm thinking of entire source trees. Given a patch to
produce a different kernel version, I would release the appropriate version,
apply the patch, and check it in as the new version. I'm *not* thinking of
file-by-file browsing because the most interesting stuff isn't there --- we
are most likely to find full source releases, not patches sitting around,
and it's unlikely that interim patches for older releases (i.e. the
equivalent of 2.0.35ac*) have survived. And, as you noted, even the patches
aren't guaranteed to produce official released source trees.
Given the limitations of what is available to us, I don't see an urgent need
to try to reconstruct an actual development tree. Future kernel development
via Bitkeeper or etc. is probably a very good idea, but trying to force
earlier kernels into the mold is more likely to be an exercise in
frustration than anything else. If we already had a reliable CVS tree
covering a significant part of the development cycle (vger doesn't, as
Linus's releases don't tie to it) then migrating it to Bitkeeper would make
sense, but as is it's just going to frustrate you unnecessarily....
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu carnegie mellon / electrical and computer engineering KF8NH Kiss my bits, Billy-boy.
- 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/