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

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

Paul Mundt wrote:
> 
> On Wed, Aug 01, 2001 at 09:32:29PM +1000, Greg Banks wrote:
> >   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?
> >
> >   What happens if 2.5.x is released before this gets organised (a real
> > possibility)?  Do we then generate two seperate drop-in trees?
> >
> This is just a matter of maintaining two drop-in trees. They could just
> be tagged as development and stable branches and be dealt with accordingly
> under CVS. The PPC tree uses the same sort of convention, except they don't
> do drop-in trees, and they use BitKeeper for source control.
> 
> This isn't really that big of a deal..

  I'm not raising objections, just trying to figure out exactly what M.R.
is proposing here so that I can have an informed opinion.

> the best way to do it would be to have
> one person handling the stable, and someone else handling the experimental.

  Sounds like a good idea.

  But it seems to me that would make using CVS branches even messier than usual.
For example, when files get renamed or moved to different directories in the
experimental branch.  As the drop-in trees are much smaller than the full kernel,
wouldn't it be simpler to have two CVS modules, one each for stable and
experimental trees?

  You may be able to tell, I've had *bad* experiences with CVS branches before.

> Either way, dealing with a drop-in tree cuts down maintenance time drastically.

  I believe it's possible, but I'd like to see it demonstrated.  What we
have now is clunky and painful for everyone, but we know how to make it
work.  I'd like to see a plan for improvement which also works.  Practically,
this means:

1.  procedures are feasible
2.  everyone understands how they work
3.  Niibe-san agrees with it

> In addition to this, it might be useful to start using proper CVS branches
> and tags in CVS to make maintenance and such easier. ie, everything can be
> under the same module in CVS, and newer revisions are simply inserted under
> their own tag on their respective branch.. with the head always pointing to
> the current stable.

  Fmeh.

  I like CVS tags, and we used to use them up until 2.4.0-test3-pre5.
I suspect Niibe-san stopped using them because with a full kernel
they take so long and don't win you anything you can't do with
a "cvs co -D".  With a drop-in tree, the trade-off changes.

  I don't like CVS branches, especially the futzing that goes on around
adding, renaming, or moving files in one or both branches.  CVS branches
are adequate for small experimental excursions which get merged back
into the mainline after a few revisions.  However for large diverging
changes like the experimental kernel, they're Trouble.  I'd be a lot
happier with two modules.

> 
> > > 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?".
> >
> You would have to think long and hard about any disadvantages to a drop-in
> tree that you wouldn't have to an entire tree. With the drop-in tree design,
> you only ever touch that which is necessary to be modified by the tree. There
> is no reason to track other changes in the tree, as they don't concern the
> tree, and are just a wasted effort.

  I agree, that's why the question is not "can it be better?" but "will it work?".

> > > As long as the drop-in tree can be easily sync'd with mainline patchlevels,
> >
> >   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.
> >
> Manual merging should be nothing short of a last resort. CVS deals with
> branch merging just fine for the most part, and the few rejects it leaves
> can be cleaned up by hand afterwards. It's totally counter productive to do
> merges by hand of everything when the source control tool can deal with the
> majority of it for you.

  Sorry, I wasn't being clear here.  I'm not talking about manually doing
the textual merge of two streams of changes to the same file, which CVS
does on "cvs up".  This is *not* the problem.  We do have several files
where this happens, such as our changes to kernel/ or mm/, and sometimes
Linus makes changes in SH-specific code.  CVS handles these just fine.

  The problem is that after CVS has done the textual merge, more subtle
problems appear, which need to be found and fixed manually.  To construct
a synthetic example, imagine that the mainline changed the name of a
field in struct console.  This then causes one of our files, drivers/char/sh-sci.c
to fail to compile (it uses named field initialisation of a static
struct console).  So we need to tweak our file to follow the global change.

  Note of course, this is an *easy* one.  The breakage is deliberate, occurs
at compile time and the fix is obvious.  Now when subtle behaviours of VM
functions change...

  This is the gnarly manual step I've been referring to.

  While deliberate breakage happens relatively infrequently in the stable
kernel, accidental breakage happens often enough to make each merge an
adventure.  Both deliberate and accidental breakage will happen a *lot* in
the early days of the new experimental kernel, as all the patches people
have been holding off sending to Linus go flooding in.

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.