From: M. R. B. <mr...@0x...> - 2001-11-08 01:51:47
|
* Jeremy Siegel <js...@mv...> on Wed, Nov 07, 2001: >=20 > (1) Of the four files to be changed, two aren't in the drop-in tree yet. > I'm assuming we expect to regularly add/drop files in common areas as > SH development proceeds, then gets put in kernel.org (or vice-versa, > if SH lags and then catches up). >=20 Yes. > (2) The MTD files are maintained by David in his own CVS; he'd like > versions in SH (or kernel.org) trees to keep keywords unchanged for > easy comparison with his tree. Our old kernel module had -ko on all > the mtd files to do this, but I don't think the drop-in does; I will add = it > for these files (and the new ones for (1) above). [How and when to > do this should probably be covered in the developer document?] >=20 Hmm, I wasn't around back then so I wasn't aware of the keyword preservation. There is a document (which still lives on linuxsh.org) that describes how to import new kernel releases, but it was never really followed ... which is the main reason it's hard to track the CVS source versions. > Any objections to these? If it's a serious problem, I don't mind just > waiting in this case for the changes to percolate from David to Linus > to SH... but certainly we need to be able to do these things smoothly. >=20 No objections, but with your last suggestion (below) it seems that you probably would want to wait until we "retrofit" the drop-in tree. > (3) In the past few weeks I've checked in some changes; in each > case I've changed all three development lines (kernel, linux:HEAD, > linux:linux-2_4-branch) -- mainly because they're all pretty much > the same at this point, and I don't want to be the one to start the > disconnect. Is that ok? I don't think there have been many other > changes (which might be helpful for the next item). >=20 I guess my preference would be to commit to branch and then merge back with HEAD, it seems we can do that until we either decide to start moving files around in HEAD, or 2.5 hits the streets, whichever comes first. > (4) Chatting with one of our architects here (Marcus, I think you > know Gilbert?) about the drop-in trees, I mentioned that I'd asked > for the old kernel tree to stay for history purposes since the new > linux modules believe last month was the dawn of time. He thought > the drop-in trees could be made by simply copying the kernel module > and deleting all the files that weren't needed, resulting in the same > (pruned) tree [though with different actual version numbers inside] > but with all the old history. Any thoughts on the value of that? >=20 Wow, that's a great idea! I've been a bit scarce in the LinuxSH world as I'm busy working on a project for MV, but I should at least have some time this weekend to complete that, unless you (or someone else) would like to get to it before then. M. R. |