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

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

* Greg Banks <gb...@po...> on Wed, Aug 01, 2001:

> 
>   So, when 2.5 is released, we start up a second drop-in tree
> for 2.5.x, while keeping the first 2.4.x drop-in tree?

Yes, because 2.4.x will still continue to be maintained and upgraded, and
we'll have to remain on our toes to fix breakage.

> 
>   What happens if 2.5.x is released before this gets organised (a real
> possibility)?  Do we then generate two seperate drop-in trees?
> 

Well, I'm working on getting the list together of files that are affected
by the move.  I still think that we'll benefit from a drop-in tree with 2.4
code as well as 2.5, so yeah, I'd be willing to continue to reorganize 2.4
if that happened.

Don't jinx me though :).

> > Now the argument may be "why abandon the current full kernel tree then?" 
> 
>   I think the argument is "how can we make a drop-in tree workable for us?".
> 

I almost have a *real* answer for this.

> > What *were* we gonna do when 2.5 hit, import that entire
> > tree into CVS?
> 
>   No idea.  But I wanted to hear *your* ideas.
> 

Oh, I was wondering if anyone else had thought of that.  My idea is to
simply start a new drop-in tree.

> 
>   The two main reasons are
> 
> 1.  SH hardware behaves slightly differently from x86 and lots of other
>     platforms and this causes changes that are harmless on those platforms
>     to break LinuxSH.  I'm thinking of the cache here.
> 
> 2.  LinuxSH depends (in both obvious and subtle ways) on functionality and
>     behaviour in the kernel which mutates from release to release.  This
>     is of course a problem with any port.
> 
[...]
> 
>   It's not every change that breaks LinuxSH, it's one of the several dozen
> which make up a release.  This sort of hassle is pretty much inevitable
> when any large body of software depends so intricately on another.
> 
>   This is why the merging is a manual process.
> 

Thanks for the heads-up.

> 
>   I don't see how.  It will require someone -- almost certainly Niibe-san --
> to do frequent time-consuming merges.  Just like he does now.  The difference
> is that the final check-in will be much smaller.
>

Yes, and working with the smaller subset of files helps to ease that process.

> 
> > When I come up with some technical answers, I'll post them here and write
> > them in a set of guidlines (part of the developers guidelines perhaps?).
> 
>   I'm looking forward to it.
> 

I have the procedures to maintain the new tree, I just have to go through
them to make sure they work :).  I'll be posting instructions soon.

> 
>   This seems unnecessarily complex, for a handful of files in each directory.
> How about
> 
> arch/sh/cchips/hd6446x/
> 

That's fine.

M. R.