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

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Wed, Aug 01, 2001:

> Thanks a lot.  Well written.  I think that change of structure and the
> move towards only maintaining SuperH portion are good idea.  If
> possible, it's good we can adopt such a new way of development for
> 2.5.
> 

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 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.
> 

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?

> (2) Changes done in mainline
> Occasionally, the changes will be done in the mainline source.
> We need to include the changes to our repository.  This'd be a kind
> of special work.  Does it require to send the changes to review?
> Who will do it, and how?  Sometimes we can't identify who does the
> change and don't understand the intention why we need the change.
> 

Well, by using a drop-in tree, we only have to worry about mainline changes
to code that falls under the LinuxSH.  From my understanding, anyone who
attempted to patch LinuxSH from outside the community would have to consult
with you as the LinuxSH maintainer.  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.

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.

> (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 :).  Based on what you wrote earlier regarding the
xengine performance, I'm eager to build the latest kernel for my Dreamcast
to see how much better it runs compared to 2.4.3 :).

Marcus