Menu
▾
▴
linuxsh-dev
|
From: M. R. B. <mr...@0x...> - 2001-10-15 21:27:36
Attachments:
treelink.sh
|
Ok, I've imported a "drop-in" tree into a new CVS module called linux. This tree exploits the branch feature of CVS to allow concurrent development of both the 2.4 and 2.5 kernel trees. By maintaining branches (as opposed to two seperate "stable" and "devel" modules) I can do janitoral work in say, include/asm-sh/dma.h, and merge those changes back into the 2.4 tree or vice versa. CVS HEAD is against 2.5.0, so all 2.5 development takes place in HEAD. The linux-2_4-branch is for 2.4.x development. This is similar to the approach the gcc developers use, where HEAD is 3.x development but there is a gcc-3_0-branch (for 3.0.1, 3.0.2, etc.). This has worked well for that group and I think it'll be equally beneficial here. Anyway, if you plan on doing development in both trees (2.5 and 2.4) you should check out HEAD and move that directory to linux-2.5 or whatever. Then, checkout the 2.4 branch (cvs co -r linux-2_4-branch linux) and move that to linux-2.4. This is the easiest way to work on both trees simultaneously. Also, if you note the version of the AGAINST file in the toplevel directory, it denotes the kernel version that the drop-in tree should be applied against. Since this a drop-in tree as opposed to the full kernel source, syncing from Linus should be a lot simpler, but it comes with it's own complexites. I'm currently writing a doc that explains this process. As far as what does and doesn't belong in the drop-in tree (so we can keep the tree "lean n' mean") the basic rule is: If it was written by a LinuxSH developer specifically for a LinuxSH target/platform, then it stays in the drop-in tree. OTOH, something like mm/vmscan.c, once it's in sync with Linus and doesn't require any SH-specific changes, should be removed from the drop-in tree. LinuxSH currently "owns" files in include/asm-sh, include/linux, arch/sh, and various driver/ subdirectories. Perhaps, in addition to the normal copyright and GPL comment at the top of the source file, we should say "This file is part of the LinuxSH project (linuxsh.sourceforge.net)" ? I've attached the treelink.sh script which is used to overlay a drop-in tree on top of a full kernel tree. I can also make a file release for this script, but I don't have any of those (file release) admin priveledges. NIIBE, Paul, or Greg, can you make me a release admin? To make this easier for developers (even though using the treelink.sh script is easy enough) and end users, we should start making file releases at kernel point releases for the full kernel tree, so that an end user can download the point release and build it normally. We can also do it for -pre releases if demand is high enough. Anyway, I need to finish the new CVS docs, I'll be updating the web CVS once they're ready. We should probably wait a good week or so for people to get adjusted to the drop-in tree before killing off the kernel tree. binutils, gcc-core, and gdb should be killed immediately. M. R. |
|
From: M. R. B. <mr...@0x...> - 2001-10-15 21:42:10
|
* M. R. Brown <mr...@0x...> on Mon, Oct 15, 2001: >=20 > Anyway, if you plan on doing development in both trees (2.5 and 2.4) you > should check out HEAD and move that directory to linux-2.5 or whatever. > Then, checkout the 2.4 branch (cvs co -r linux-2_4-branch linux) and move > that to linux-2.4. This is the easiest way to work on both trees > simultaneously. Also, if you note the version of the AGAINST file in the > toplevel directory, it denotes the kernel version that the drop-in tree > should be applied against. >=20 One quick note on tag naming conventions: This'll be covered in the doc, but anyway, the convention is "linux", followed by the version number (with periods replaced by underscores), and any -pre designation. If it's a series branch, then it's the same as above, but only with the kernel series version number, followed by -branch. So, if you were about to update the 2.4 branch from 2.4.13-pre2 to 2.4.13, you'd tag it with "linux-2_4_13-pre2". Note that you always tag against the last kernel version you *were* working with, not the version you're going to (since that's current). Still working on the docs.. M. R. |
|
From: NIIBE Y. <gn...@m1...> - 2001-10-16 10:47:57
|
Thanks a lot for your effort. Yes, I'll arrange the privilege of you. I'm not familiar to the use of sourceforge.net (except CVS). Honestly speaking, I'm not good at using the interface through WWW browser. I think that I could find the way to do that in a day or two, please wait. -- |
|
From: M. R. B. <mr...@0x...> - 2001-10-16 16:41:11
|
* NIIBE Yutaka <gn...@m1...> on Tue, Oct 16, 2001: > Thanks a lot for your effort. Yes, I'll arrange the privilege of you. >=20 > I'm not familiar to the use of sourceforge.net (except CVS). Honestly > speaking, I'm not good at using the interface through WWW browser. >=20 > I think that I could find the way to do that in a day or two, please > wait. Actually Paul Mundt already granted me admin priveledges, so no need to worry about it :). On a related note, I plan on stepping up to do more Sourceforge maintenance, I'll describe that in another e-mail. M. R. |
|
From: Greg B. <gn...@al...> - 2001-10-16 13:04:43
|
"M. R. Brown" wrote: > > Ok, > > I've imported a "drop-in" tree into a new CVS module called linux. Excellent, I'm glad to see this progressing. I just "cvs co"d it, it's certainly a lot quicker than the full tree! > I'm currently writing a doc that explains [the syncing-with-Linus] process. I'm looking forward to that. > Perhaps, in addition to the > normal copyright and GPL comment at the top of the source file, we should > say "This file is part of the LinuxSH project (linuxsh.sourceforge.net)" ? Sounds good to me. > I've attached the treelink.sh script which is used to overlay a drop-in > tree on top of a full kernel tree. I can also make a file release for this > script, but I don't have any of those (file release) admin priveledges. > NIIBE, Paul, or Greg, can you make me a release admin? Why don't you check this script into CVS, under linux/scripts/ ? Also, it might be nice to have files which are replaced (rather than added) by treelink.sh backed up, so there's something like a mm/vmscan.c.orig. This saves a lot of futzing about to get per-file diffs later. > Anyway, I need to finish the new CVS docs, I'll be updating the web CVS > once they're ready. We should probably wait a good week or so for people > to get adjusted to the drop-in tree before killing off the kernel tree. At least. > binutils, gcc-core, and gdb should be killed immediately. Good riddance. Greg. -- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001. |
|
From: M. R. B. <mr...@0x...> - 2001-10-16 16:53:56
|
* Greg Banks <gn...@al...> on Tue, Oct 16, 2001: >=20 > > I've attached the treelink.sh script which is used to overlay a drop-in > > tree on top of a full kernel tree. I can also make a file release for = this > > script, but I don't have any of those (file release) admin priveledges. > > NIIBE, Paul, or Greg, can you make me a release admin? >=20 > Why don't you check this script into CVS, under linux/scripts/ ? >=20 Sure. > Also, it might be nice to have files which are replaced (rather than > added) by treelink.sh backed up, so there's something like a mm/vmscan.c.= orig. > This saves a lot of futzing about to get per-file diffs later. >=20 Ah, great idea! I'll add that right away :). > > Anyway, I need to finish the new CVS docs, I'll be updating the web CVS > > once they're ready. We should probably wait a good week or so for peop= le > > to get adjusted to the drop-in tree before killing off the kernel tree. >=20 > At least. >=20 Actually, I have another "agenda", I've been playing with the web sources, and I'm doing some major restructuring locally. You can find the test version at http://alphaflight.d6.dnsalias.org:8008/. So far the only changes I've done are renaming all .php3 files to .php and some other minor cleanups, but I plan on doing some reorganization of "Documents", as well as bringing everthing to XHTML compliance :). There some new features I'm going to sneak into the site, like a "Boards" type of section (working/status of SH boards), and some other surprises. That'll be happening in the next few days. > > binutils, gcc-core, and gdb should be killed immediately. >=20 I'm filing the appropiate SR now. I've also killed all of the cruft in the /home/groups/l/li/linuxsh directory (test kernels, other misc. unrelated sources). I plan on stepping up to do website maintenance, but I also plan to maintain the SourceForge backend as well, I'll post on that seperately. M. R. |
|
From: Greg B. <gn...@al...> - 2001-10-17 13:27:40
|
"M. R. Brown" wrote: > > * Greg Banks <gn...@al...> on Tue, Oct 16, 2001: > > [...] I've been playing with the web sources, > [...] There some new features I'm > going to sneak into the site, like a "Boards" type of section > (working/status of SH boards), and some other surprises. Ok. Let me know if you need to know the password for MySQL access on sourceforge. > I plan on stepping up to do website maintenance, Good! Greg. -- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001. |
|
From: M. R. B. <mr...@0x...> - 2001-10-16 21:56:05
|
* Greg Banks <gn...@al...> on Tue, Oct 16, 2001: >=20 > Why don't you check this script into CVS, under linux/scripts/ ? >=20 > Also, it might be nice to have files which are replaced (rather than > added) by treelink.sh backed up, so there's something like a mm/vmscan.c.= orig. > This saves a lot of futzing about to get per-file diffs later. >=20 Ok, I've committed the treelink.sh and treeunlink.sh scripts. treelink.sh makes symlinks from a drop-in tree within a full kernel tree, and any files that it modifies it saves in a .orig subdirectory. So to get diffs within a directory, use either `diff -u .orig/foo foo` or `diff -u .orig/ .`. The treeunlink.sh script restores the full kernel tree to the state it was in before treelink.sh got to it, barring any directories that existed in the drop-in tree but not in the kernel tree. I'll fix that later. Hmm, I haven't yet tried dropping a drop-in tree on top of a drop-in tree (e.g. `treelink.sh linux-2_4-branch linux-2.4.13-pre2` followed by `treelink.sh linux-sh-dc linux-2.4.13-pre2`), but I don't see why it wouldn't work. treeunlink.sh eradicates all symlinks within the tree, so you should still be able to fully restore the tree if necessary. Also, under one or two rare instances vim replaced the symlink with a regular file, but I don't remember what I was doing, so if anyone runs into this let me know. M. R. |
|
From: Jeremy S. <js...@mv...> - 2001-10-17 22:44:07
|
Greg Banks wrote: > "M. R. Brown" wrote: > > Anyway, I need to finish the new CVS docs, I'll be updating the web CVS > > once they're ready. We should probably wait a good week or so for people > > to get adjusted to the drop-in tree before killing off the kernel tree. > > At least. I'd request that the kernel actually stick around quite a bit longer for historical value: seeing when/where/who/why a given change went in, or isolating some symptom to a particular delta. Thanks, --Jeremy Siegel |
|
From: M. R. B. <mr...@0x...> - 2001-10-17 23:00:30
|
* Jeremy Siegel <js...@mv...> on Wed, Oct 17, 2001: >=20 > I'd request that the kernel actually stick around quite a bit longer for > historical > value: seeing when/where/who/why a given change went in, or isolating some > symptom to a particular delta. >=20 You're going to have a hard time doing that with the legacy kernel/, given the fact that no one ever bothered to tag sync-ups with Linus. It would be very tedious to try and find specific kernel releases by grepping cvs logs and so forth. But if someone wanted to take the effort to do so, I'd rather they grab specific kernel releases and archive them, so that we can eventually kill that tree. I agree on keeping it around to be able to track changes, but I want to at least get my docs out and freeze that tree, so we start using the drop-in tree by next week. In the new drop-in tree *everything* will be tagged (or your changes will be reverted). M. R. |
|
From: Jeremy S. <js...@mv...> - 2001-10-17 23:23:51
|
"M. R. Brown" wrote: > * Jeremy Siegel <js...@mv...> on Wed, Oct 17, 2001: > > > > > I'd request that the kernel actually stick around quite a bit longer for > > historical > > value: seeing when/where/who/why a given change went in, or isolating some > > symptom to a particular delta. > > > > You're going to have a hard time doing that with the legacy kernel/, given > the fact that no one ever bothered to tag sync-ups with Linus. Yeah, I know... can't even use dates since things happen on the same day (and I haven't fully groked how the -D and the respository manage timezones!) > It would be very tedious to try and find specific kernel releases by > grepping cvs logs and so forth. But if someone wanted to take the effort > to do so, I'd rather they grab specific kernel releases and archive them, > so that we can eventually kill that tree. > > I agree on keeping it around to be able to track changes, but I want > to at least get my docs out and freeze that tree, so we start using the > drop-in tree by next week. > > In the new drop-in tree *everything* will be tagged (or your changes > will be reverted). I can't argue with it being frozen, and I really like the plan to tag all changes. Thanks for doing all this work, Marcus! --Jeremy Siegel |
|
From: M. R. B. <mr...@0x...> - 2001-10-16 16:43:38
Attachments:
treelink.sh
|
Ok, I've imported a "drop-in" tree into a new CVS module called linux. This tree exploits the branch feature of CVS to allow concurrent development of both the 2.4 and 2.5 kernel trees. By maintaining branches (as opposed to two seperate "stable" and "devel" modules) I can do janitoral work in say, include/asm-sh/dma.h, and merge those changes back into the 2.4 tree or vice versa. CVS HEAD is against 2.5.0, so all 2.5 development takes place in HEAD. The linux-2_4-branch is for 2.4.x development. This is similar to the approach the gcc developers use, where HEAD is 3.x development but there is a gcc-3_0-branch (for 3.0.1, 3.0.2, etc.). This has worked well for that group and I think it'll be equally beneficial here. Anyway, if you plan on doing development in both trees (2.5 and 2.4) you should check out HEAD and move that directory to linux-2.5 or whatever. Then, checkout the 2.4 branch (cvs co -r linux-2_4-branch linux) and move that to linux-2.4. This is the easiest way to work on both trees simultaneously. Also, if you note the version of the AGAINST file in the toplevel directory, it denotes the kernel version that the drop-in tree should be applied against. Since this a drop-in tree as opposed to the full kernel source, syncing from Linus should be a lot simpler, but it comes with it's own complexites. I'm currently writing a doc that explains this process. As far as what does and doesn't belong in the drop-in tree (so we can keep the tree "lean n' mean") the basic rule is: If it was written by a LinuxSH developer specifically for a LinuxSH target/platform, then it stays in the drop-in tree. OTOH, something like mm/vmscan.c, once it's in sync with Linus and doesn't require any SH-specific changes, should be removed from the drop-in tree. LinuxSH currently "owns" files in include/asm-sh, include/linux, arch/sh, and various driver/ subdirectories. Perhaps, in addition to the normal copyright and GPL comment at the top of the source file, we should say "This file is part of the LinuxSH project (linuxsh.sourceforge.net)" ? I've attached the treelink.sh script which is used to overlay a drop-in tree on top of a full kernel tree. I can also make a file release for this script, but I don't have any of those (file release) admin priveledges. NIIBE, Paul, or Greg, can you make me a release admin? To make this easier for developers (even though using the treelink.sh script is easy enough) and end users, we should start making file releases at kernel point releases for the full kernel tree, so that an end user can download the point release and build it normally. We can also do it for -pre releases if demand is high enough. Anyway, I need to finish the new CVS docs, I'll be updating the web CVS once they're ready. We should probably wait a good week or so for people to get adjusted to the drop-in tree before killing off the kernel tree. binutils, gcc-core, and gdb should be killed immediately. M. R. |
|
From: M. R. B. <mr...@0x...> - 2001-10-16 16:43:40
|
* M. R. Brown <mr...@0x...> on Mon, Oct 15, 2001: > > Anyway, if you plan on doing development in both trees (2.5 and 2.4) you > should check out HEAD and move that directory to linux-2.5 or whatever. > Then, checkout the 2.4 branch (cvs co -r linux-2_4-branch linux) and move= > that to linux-2.4. This is the easiest way to work on both trees > simultaneously. Also, if you note the version of the AGAINST file in the= > toplevel directory, it denotes the kernel version that the drop-in tree > should be applied against. > One quick note on tag naming conventions: This'll be covered in the doc, but anyway, the convention is "linux", followed by the version number (with periods replaced by underscores), and any -pre designation. If it's a series branch, then it's the same as above, but only with the kernel series version number, followed by -branch. So, if you were about to update the 2.4 branch from 2.4.13-pre2 to 2.4.13, you'd tag it with "linux-2_4_13-pre2". Note that you always tag against the last kernel version you *were* working with, not the version you're going to (since that's current). Still working on the docs.. M. R. |
|
From: M. R. B. <mr...@0x...> - 2001-10-16 16:43:42
|
* M. R. Brown <mr...@0x...> on Mon, Oct 15, 2001: > > Anyway, if you plan on doing development in both trees (2.5 and 2.4) you > should check out HEAD and move that directory to linux-2.5 or whatever. > Then, checkout the 2.4 branch (cvs co -r linux-2_4-branch linux) and move= > that to linux-2.4. This is the easiest way to work on both trees > simultaneously. Also, if you note the version of the AGAINST file in the= > toplevel directory, it denotes the kernel version that the drop-in tree > should be applied against. > One quick note on tag naming conventions: This'll be covered in the doc, but anyway, the convention is "linux", followed by the version number (with periods replaced by underscores), and any -pre designation. If it's a series branch, then it's the same as above, but only with the kernel series version number, followed by -branch. So, if you were about to update the 2.4 branch from 2.4.13-pre2 to 2.4.13, you'd tag it with "linux-2_4_13-pre2". Note that you always tag against the last kernel version you *were* working with, not the version you're going to (since that's current). Still working on the docs.. M. R. |
|
From: Jeremy S. <js...@mv...> - 2001-11-08 00:41:22
|
I've got several questions regarding management of our CVS trees, which I haven't seen covered in any how-to-use description. If I've simply missed stuff in a document somewhere, please let me know. (The context for this is that I've recently made some changes to mtd files with dwmw2's blessing, and wanted to put them in our tree, so this kind of details what I think I'll be doing... but here's your chance to correct me if I'm going to do anything horribly wrong!) (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). (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?] 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. (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). (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? Well, that's all for now... --Jeremy Siegel |
|
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. |
|
From: Jeremy S. <js...@mv...> - 2001-11-08 18:39:46
|
"M. R. Brown" wrote: > No objections, but with your last suggestion (below) it seems that you > probably would want to wait until we "retrofit" the drop-in tree. I'll put the stuff in the way I have been; as long as the trees all remain pretty much in sync (actually, as long as "kernel" doesn't fall behind) any "retrofit" will not be affected. (The relief of having it checked in at all is greater than the burden of doing multiple check-ins!) > 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. Seems the way to go when trees separate and you want to move deltas between branches with CVS doing most of the work! (As long as they remain basically the same, I'll probably check both in independently, and do my own copying and editing.) > > (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? > > 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. I'll defer to you -- I'm not familiar enough with repository management to believe I could do it safely. In the meantime I'll treat all three modules identically w.r.t. changes so as not to introduce any new differences into the works. Thanks! --Jeremy |
|
From: Greg B. <gn...@al...> - 2001-11-08 04:05:49
|
Jeremy Siegel wrote: > > (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,[...] I'm certainly expecting that. > (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. [...] I have no objection to -ko on MTD source files. The $Id$ should really come from the master CVS for the source file; perhaps MR can add something along these lines to the dev doc? > [...]I don't mind just > waiting in this case for the changes to percolate from David to Linus > to SH... I think that would probably be the worst solution. > [...] (kernel, linux:HEAD, > linux:linux-2_4-branch) [...] and I don't want to be the one to start the > disconnect. For "linux:HEAD" vs "linux:linux-2_4-branch", the timing is Linus' job ;-) As to whether you should spend time updating "kernel", that depends on Niibe-san. > [...] drop-in trees could be made by simply copying the kernel module > and deleting all the files that weren't needed,[...] That would be a *really* good idea if we had shell access to the CVS machine at sourceforge. I don't (offhand) know of a way to copy or remove entire ,v files remotely, but I'd be happy to have someone explain it to me. Greg. -- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001. |
|
From: Mitch D. <mj...@al...> - 2001-11-08 13:47:22
|
Greg Banks wrote: > > Jeremy Siegel wrote: > > > > [...]I don't mind just > > waiting in this case for the changes to percolate from David to Linus > > to SH... > > I think that would probably be the worst solution. Been there. If a change doesn't scratch Linus' itch, he can be a bit of a black hole. Alan might be a better bet than Linus. > > [...] drop-in trees could be made by simply copying the kernel module > > and deleting all the files that weren't needed,[...] > > That would be a *really* good idea if we had shell access to > the CVS machine at sourceforge. I don't (offhand) know of a way > to copy or remove entire ,v files remotely, but I'd be happy to > have someone explain it to me. I believe the only method is via a support request to sourceforge. So as to make things absolutely unambiguous, it might be possible to make a shell script containing rm(1)s that they can run after cd(1)ing to the relevant repository directory. Regards, Mitch. -- The GPL is a lot like an alligator snout. You can hold it shut with one hand, but if you stick your head in it bites like hell. mailto:mj...@al... - Nathan Myers |
|
From: David W. <dw...@in...> - 2001-11-08 13:57:33
|
mj...@al... said: > Been there. If a change doesn't scratch Linus' itch, he can be a bit > of a black hole. Alan might be a better bet than Linus. Linus is usually reasonably good about taking MTD code changes. The main problem is that I'm crap at actually getting round to _sending_ them :) -- dwmw2 |
|
From: Jeremy S. <js...@mv...> - 2001-11-14 01:07:00
|
Mitch Davis wrote:
> Greg Banks wrote:
> >
> > Jeremy Siegel wrote:
> > > [...] drop-in trees could be made by simply copying the kernel module
> > > and deleting all the files that weren't needed,[...]
> >
> > That would be a *really* good idea if we had shell access to
> > the CVS machine at sourceforge. I don't (offhand) know of a way
> > to copy or remove entire ,v files remotely, but I'd be happy to
> > have someone explain it to me.
>
> I believe the only method is via a support request to sourceforge.
> So as to make things absolutely unambiguous, it might be possible
> to make a shell script containing rm(1)s that they can run after
> cd(1)ing to the relevant repository directory.
So one of the project admins has to make the request? A diff of
the latest kernel and linux modules produces 1458 lines starting
with "Only in kernel", i.e. files/directories that should be pruned.
I don't know much about CVS repository management; I'd guess
the script would be something like:
mv linux linux-tmp
cp -r kernel linux
rm -rf kernel/.cvsignore
rm -rf kernel/.gdbinit-dmida
rm -rf kernel/.gdbinit-sesh3
... (et cetera, et cetera) ...
rm -rf kernel/scripts/usb
rm -rf kernel/scripts/ver_linux
Then using normal procedures an admin (or anyone) could add
scripts/tree*link.sh, make the linux-2_4-branch, add the tags,
add the AGAINST-* files, then make the appropriate changes
to ChangeLog and kernel/ksyms.c based on linux-tmp. (The
latter is the only code difference between the branches, but
doesn't seem like it's really needed?) Then linux-tmp can
be removed, and eventually kernel, w/o (as much) loss of
history.
Do we need a vote or something? I don't feel that strongly
about whether we should do it or not, but I DO feel that if we
are going to do it, it should be soon... and I'd certainly feel a
lot more comfortable killing the kernel module if I knew the
history were still accessible.
--Jeremy Siegel
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X