Re: [tlug] Open-source repository question

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:
 > On 2009-09-28 20:01 +0900 (Mon), Stephen J. Turnbull wrote:

 > > I told you this is a leprous codebase.
 > > ...
 > > Again, the only reasonable way to deal with this is to put them on a
 > > feature branch until either they start consistently running the tests.
 > 
 > Hm. This is starting to sound like, "horrible code base, idiot developers,
 > but hey, with git's branching, all of this is no problem now!"

I didn't say there was "no problem", and I certainly didn't mean that.

What I do mean to say is that it's going to be a very long hard road
to anything resembling CI, and in the meantime cheap branching and
cheaper-than-CVS-or-SVN<1.5-at-least merging reduces a lot of
unnecessary costs.  Both transactions costs for people trying to
submit patches, and branch maintenance costs for resynching from the
mainline and code getting dropped on the floor because the patches got
eaten by the Temp Reaper or something.  (git would be even better than
Mercurial for this, but that's another story.)

 > > I'm confused.  I thought the "first step" we are taking here is
 > > toward CI.
 > 
 > Oh, sorry; I was under the impression that you guys were
 > maintaining separate branches for various features. Probably it's
 > just the article echoing through my head.

No, the feature branches that I talk about are spontaneous.  Many
occur because code gets rejected (either by the dev or by a reviewer)
and needs to be reworked.  Others occur because the dev just never
gets the code into usable state.

 > With what I was trying to say, that statement would be that "any decent
 > VCS" will take two gui.c files, a Mac one that won't compile under Linux
 > and a Linux one that won't compile under the Mac, find new, separate
 > locations to put the two, and tweak the build system to find and use the
 > right one.
 > 
 > If git does this, it really has solved your idiot developer
 > problem!

OIC.  Actually, no, Jamie Zawinski and Ben Wing already did exactly
that more than a decade and a half ago.  "gui.c" is fine.  It's
"gui-x.c" and "gui-gtk.c" that cause problems.  For example ...
somebody decided they needed to get the hotspot of a cursor from Lisp.
So they changed the hotspot representation from an internal C integer
to a Lisp integer in the cursor structure (which is in "gui.h"), and
provide generic code including the Lisp binding in "gui.c".  The X and
Xt implementation is in "gui-x.c".  The GTK implementation is trivial
because (so the comment claims, anyway) GTK doesn't allow you to read
the hotspot from a cursor, let alone set it, so it was set to (1,1).
1, however, is an invalid Lisp object, so the cursor attributes need
to be initialized to make_int(1).  Not rocket science to fix, but the
coder just didn't bother, and didn't know there was a problem because
he never compiled with GTK.

Later coders also did things like add a myriad of global "dirty" flags
to redisplay to force repaint of certain objects at certain times,
rather the do the refactoring of internal routines necessary to get
each different GUI toolkit to do it just-in-time by its conventions.

It's just a lack of discipline.  No follow-through on new features,
and I think more important, not enough interest in studying the
structure of the program.

But it's hard to impose discipline on unpaid volunteers.  Eg, I kept
code to support Xft to XEmacs on a branch for over a year because of
lack of follow-through.  Finally the other reviewers ganged up on me
and argued that (a) I was wrong because the bugs were pretty obvious
things (no usable font selection dialog, for example), and if we just
put it in people would use it and submit fixes, and (b) they would
just override my veto if I didn't cave anyway. :-)  I was right, they
were wrong.  The bugs get fixed bit by bit when *I* have time to work
on them, and in the meantime the PRs pile up in the tracker.

 > Right. And that's where I think things didn't go so well; it feels as if
 > (talking out of my ass, here) once a band-aid was found, nobody carried
 > on with addressing the deeper systematic problems, if they ever were
 > addressing them in the first place.

Well, that's the sad thing.  The Lucid fork was all about resolving
"deeper systemic problems"; Lucid Emacs was designed by one of the
leading edge software engineering firms of the time after all.
(Unfortunately they chose to back Lisp....[1])  However, once first
Lucid folded and then Sun cut off financial support, things went to
pot steadily.  It's still a pretty good design[2] under all the cruft,
but digging it out ... I wonder if Hercules will be for hire?  He did
a great job with the Augean stables!

Footnotes: 
[1]  Which I love, as you know, but the world doesn't.

[2]  Hobbyists and grad students regularly implement features in
XEmacs (or its derivatives) in a couple months that GNU Emacs takes
years, sometimes a decade or more, to catch up to.  But they were toys
when implemented and stay toys until GNU picks them up, then suddenly
it's "look at the cool things you can do with GNU Emacs!"  To add
insult to injury, they invariably implement a far less powerful and
often wrong-headed API....