On Sun, Apr 21, 2002 at 11:58:57AM +1000, Brian Spilsbury wrote:
> William Harold Newman wrote:
> >On Sun, Apr 21, 2002 at 02:01:34AM +1000, Brian Spilsbury wrote:
> >>William Harold Newman wrote:
> >>>You wrote elsewhere that you'd like to have the code in the SBCL CVS
> >>>codebase. That's entirely understandable after you had to drag the
> >>>patch through all the 0.pre7.* rearrangement (though hopefully that's
> >>>a one-time event, or at least a once-in-a-decade event, not a regular
> >>>event). Anyway, it seems to me that most of the benefit there would
> >>>follow from part 1, for more or less the loose-coupling reasons
> >>>discussed below.
> >>What I'd really prefer is to have a side-branch in the SBCL CVS, which
> >>can be used to bring this code into line with the main branch.
> >(You mentioned this "side branch" idea elsewhere, too.)
> >Do you just mean an ordinary CVS branch where changes from the main
> >branch are periodically merged? If so, it seems to me that this would
> >be very nearly equivalent to you maintaining your own CVS repository
> >for a +Unicode variant of SBCL, and periodically doing "cvs diff"
> >between versions of the main SBCL and applying the resulting patches
> >to your repository version. The main difference I can see would be
> >that when the repositories were the same, then the administrative
> >issues -- syncmail issues, commit permissions, and maybe other stuff
> >like URLs and the schedule for freezes and releases -- would tend to
> >interact more, while if the repositories were separate, the
> >administrative issues would tend to be independent.
> >If this is what you mean, my first impulse would be to keep the
> >+Unicode repository separate, instead of a branch in the main
> >repository, because the administrative interaction could easily be
> >more of a nuisance than a benefit.
> I haven't actually tried cvs branches :)
> I guess I mean a conceptual branch, the method of implementation isn't
> important to me.
> One thing that I do think is important is that whatever is done, it ends
> up being done in the central sbcl place, with ultimate administration by
> yourself, in order to avoid a fork/split, and to facilitate access by
> the usual methods.
I don't really want to administer it until it's pretty stable. It's a
chore which I'm not so motivated to do for code that doesn't strictly
have to be integrated yet, and it's a responsibility that I'm less
comfortable with as decisions move away from "is it a bug?" and "is it
an incremental improvement?" into de novo design of large systems.
From what you wrote elsewhere, I think you hoped that having the
source as a branch in the main repository would cause it to be kept it
up to date with respect to changes in the main branch. Unfortunately,
as far as I can see, that wouldn't really help. Branches suffer code
rot just as separate patches do, since people do maintenance work in
checked-out copies of the main branch, where other branches are
invisible. Thus, you have to combat the code rot by essentially the
same manual repair work as you'd use on separate patches. Putting the
Unicode code in the same branch as the main code (e.g. with #!+ flags)
would help (because it becomes easy to notice when a change will
affect the Unicode code). Beyond that, keeping the Unicode code in an
bootstrappable state with good test cases which are run periodically
would help even more. But just having it physically in the CVS
repository (in a separate branch) doesn't have much effect.
Putting the code as a branch in the main repository makes it visible
to the world, but only barely. Not many people are going to be
sophisticated and motivated enough to find and check out a CVS branch,
and I'd guess that most of them are also S&M enough to download a
separate patch and apply it.
My flakyX unstable development branches, which still exist, illustrate
both these points. They've suffered enormous code rot since I resumed
working on the main branch. And I didn't get as much feedback on the
flakyX branches as on the ordinary code.
Having a public CVS repository can be valuable, and being in the main
SBCL repository would get you that. But
(1) It's my guess that the value of a public CVS repository is
greater for stable code (in the "is it a bug?" and "is it
an incremental improvement?" limit) than for design work.
In the stable limit, parallel work is relatively easy. In
design work, parallel work is relatively hard. I doubt
that a public CVS repository would have helped me all
that much in the process of getting SBCL to bootstrap,
or would help Dan now in the process of MPizing SBCL.
(2) If you find that I'm wrong about the value of public CVS
for the kinds of work you need to do, you can make your
repository public separately, through SourceForge if
necessary. That's still separate from the issue of forking
> I think that something similar might also be necessary for other
> projects with far-reaching effects, such as daniel barlow's threading
> The idea I have of these is something like 'temporary detours', rather
> than forks :)
I too prefer to avoid a fork! (If you made a separate +Unicode version
of SBCL, we'd probably have to steal the Unicode code as a separate
step, and that seems like unnecessary trouble.:-) But the forking issue is
largely separate from the branching issue.
* If SBCL had been a branch in the main CMU CL repository, there'd
still have been a fork, because I'd still have been unmotivated to
drag the rest of the CMU CL codebase and practices along, and the
CMU CL people would still have been unmotivated to merge the
rather drastic surgery in SBCL back into the main codebase.
* Dan Barlow and Christophe Rhodes have done large changes in their
own CVS repositories, merging them into the main codebase
when they're stable (Alpha, SPARC, and PPC so far, maybe
> Does that sound reasonble?
Your goals sound reasonable. I think we mostly agree about goals, and
disagree about policy because of differences of opinion about the
actual consequences of policies. Such disagreements are supposed to be
easier to resolve than disagreements about goals...
William Harold Newman <william.newman@...>
Users like this are like a mongoose backed into a corner: with its back to
the wall and seeing certain death staring it in the face, it attacks
frantically, because doing something has to be better than doing nothing.
This is not well adapted to the type of problems computers produce.
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C