Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[Greg B. <gb...@po...>]

"M. R. Brown" wrote:
> 
> Well, I'm willing to be a bit more ambitious and commit to getting the
> current tree restructured, not waiting for 2.5.  Sure it will take a lot of
> effort, but I think it will be beneficial in the long run.  For August I
> have basically unlimited free time to commit to working on this.  I can
> come up with a strategy for restructuring, when I get that finished I'll
> send it to the list for approval, is that ok?

  I'm looking forward to it.

> I can do my work on restructuring the tree in parallel with current LinuxSH
> development.  The current LinuxSH code is based in the kernel/ CVS
> directory, I can start the restructuring work in a directory called linux/
> at the same time.
> 
> >
> > (1) "Patch Manager"
> > We have "Patch Manager", but it's almost non-functional (no one care
> > it).  I think that the future direction is remove using "Patch
> > Manager" and require people to send all the changes to review.

  Yes, sf's Patch Manager appears pretty much superfluous.  We can't
turn it off AFAIK, so we need to make sure people know not to use it.

> I think that's a good idea.  One more thing I wanted to point out but I
> forgot: in the mailing list section on the LinuxSH SF website, it mentions
> the linux-sh and linux-sh-ja mailing lists, but neglects to mention the
> linuxsh-dev and linuxsh-cvs lists.  When I first looked at LinuxSH, I
> didn't realize that those lists existed, and I missed a good deal of
> discussion that only took place on the linuxsh-dev list.  Could someone
> update that section to add those lists?

  Actually, I deliberately left lin...@sf... out because I was 
under the impression (apparently false) that it was nearly unused.  Also
it seems to me that it offers little advantage over or differentiation
from the m17n.org list which it was meant to replace but which hasn't died.
Frankly I think it should be killed off.

  As for linuxsh-cvs, it's there already.  Perhaps you need to scroll down.

> [...]  That's the advantage of using a
> drop-in tree as opposed to including the entire kernel source in CVS - if
> there is a "global" mainline change that somehow breaks LinuxSH
> functionality, all you have to do is fix that relevant portion in the
> drop-in tree - you don't have to patch everything.

  Hah, if only it were so easy.  A drop-in tree is a good idea but
this is not a good reason for it.

> It should be easy to pick out individual patches that target LinuxSH code
> if that code comes from external sources.  I believe the package named
> 'patchutils' (in Debian) allows you to pick out individual patches within a
> patchset.

  The problems arise when subtle things change in the mainline which
are apparently unrelated to LinuxSH code but break it.  For example,
subtle behaviours of remap_page_range() changed between 2.4.0-test10
and 2.4.0, breaking my PCMCIA code.

> 
> > (3) Testing
> > It would be good if we can maintain some sort of success/failure table
> > with version and/or date.  It is good for tracking bug introduced.
> > Performance test is also good.
> 
> That's a great idea :).

  DGI (Damn Good Idea).

  Actually this was idea we had back in Mar 2000 but never got around
to implementing.  The dream was to have some kind of database attached
to the SF website which people could update.  Perhaps a less hi-tech
approach would succeed ;-)

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.