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

[Paul M. <pm...@mv...>]

On Fri, Aug 03, 2001 at 11:14:40AM +1000, Greg Banks wrote:
> > the best way to do it would be to have one person handling the stable, =
and
> > someone else handling the experimental.
>=20
>   Sounds like a good idea.
>=20
>   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?
>=20
Er, this is exactly what the branches are for. Stable development (2.4.x)
would be done on a stable branch, and experimental (2.5.x) would be done on=
 an
experimental branch. Under each branch, new versions would be done under ta=
gs.
ie, 2.4.8 comes out .. required updates are done, and result is tagged as a
2.4.8 release and pushed back into the stable branch. At this point, people
could still grab a 2.4.7 tagged repository. There's no point in that time in
maintaining old things, as the current stable and current experimental are =
the
only ones that'd be under development. Tagged previous revisions would just=
 be
there for archival, and provide a simple means for people to grab the tree =
for
their kernel version.

>   You may be able to tell, I've had *bad* experiences with CVS branches b=
efore.
>=20
The majority of bad experiences come from people improperly setting up/using
CVS branches. It's amazing the number of repositories out there that aren't
being run properly at all, simply because people don't know how to use CVS.

> > Either way, dealing with a drop-in tree cuts down maintenance time dras=
tically.
>=20
>   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.  Practica=
lly,
> this means:
>=20
> 1.  procedures are feasible
> 2.  everyone understands how they work
> 3.  Niibe-san agrees with it
>=20
#1 should be taken care of when #2 is done properly. #2 could easily be
acheived with a test tree and some documentation outlining how to use it.

#3 would follow #2 and #1 being successful, or so I would think. Though that
all depends how much Niibe-san likes drop-in trees and CVS branching/taggin=
g.

>   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.
>=20
This moving around and other such issues are only a concern when you're dea=
ling
with multiple branches of the same thing. In this case, we'd only be having=
 a
stable and an experimental branch, and then having kernel versions tagged.
Stable and experimental would have to be kept seperate anyways, so you're n=
ot
really doing any _extra_ work by doing a branched/tagged approach.

As far as CVS is concerned, they are two modules. The user just has to know
which one they want to check out.. the head should always point to the curr=
ent
stable.

> > 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 de=
sign,
> > 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.
>=20
>   I agree, that's why the question is not "can it be better?" but "will i=
t work?".
>=20
It's worked for everyone else, so I don't see it as being a hinderance here=
. I
guess we can't say one way or another until it gets tried.

>   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 chang=
e.
>=20
>   Note of course, this is an *easy* one.  The breakage is deliberate, occ=
urs
> at compile time and the fix is obvious.  Now when subtle behaviours of VM
> functions change...
>=20
>   This is the gnarly manual step I've been referring to.
>=20
>   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.
>=20
Breakage is going to happen regardless, it's unavoidable. This isn't CVS's
problem, this is something that's going to happen in any experimental tree.
(Note: that's why it's experimental, not stable). An API or some such thing
being totally restructured, or entire subsystems being swapped out for new
ones, are all common place for an experimental tree. I don't see how CVS
makes this a problem.

Perhaps I'm misunderstanding what you're getting at, but I don't see
anything you've listed above as being a problem with CVS or the drop-in tree
design. These look like nothing but general issues that arise from any kind
of kernel work across multiple revisions, and isn't something that can be
avoided. CVS makes a lot of this a lot cleaner, as it does a lot of the
work for you, you're just required to do the cleanup on stuff that rejects
or stuff that breaks afterwards. Plus, with proper tagged branches, it's
a lot simpler to track the history of things and follow API changes more
closely. Try doing that in the current tree.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.