Re: [tlug] Open-source repository question

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

Curt Sampson writes:
 > On 2009-09-28 15:03 +0900 (Mon), Stephen J. Turnbull wrote:
 > 
 > > But the only way to fix it at the root is to exclude them from the team.
 > 
 > I doubt that that's the *only* way. Have you tried pairing them up with
 > other, somewhat more responsible developers, to see if they can be
 > brought up to speed?

In XEmacs this is just not practical.  We're spread pretty uniformly
over time zones, and the responsible developers tend to get blocks of
4 hours or so at a time in Poisson process with lambda = 2 weeks.  The
irresponsible :-) developers sometimes have more time, sometimes less,
but in general they don't match with anybody else.

Might work in Linux kernel development, I dunno.

 > > That's sort of antithetical to the idea of a public project.
 > 
 > I don't see why. "Public" does not mean "accept any crap." I'm not
 > allowed to poop on the grass in public parks, despite them being
 > "public."

I don't intend to accept just any crap.  I do intend to require
quality code (FSVO of "quality").  But that means rejecting some
patches multiple times.

 > > The alternative is to reject those patches until acceptable,
 > > which is a feature branch.  No?
 > 
 > That certainly works! But if that's the case, you don't really care
 > about branching and merging costs, do you? That all falls on the
 > developer who can't be trusted, who is probably not producing great
 > work anyway.

Branching cost is near zero (in fact, since we work with Mercurial, it
is zero: every checkout is a branch).

 > That's one way, yes. :-) I tend to prefer, "run the top level test
 > script and don't commit if it doesn't work,"

Changing the GUI changes config.h.  On X, there are 4 principal GUIs
(tty-only, X-no-Xt, Xt, and GTK+).  On the Mac, there are 5 (add
Carbon to that list).  On Windows, there are 5 (add Windows native to
that list).  There's Mule and no-Mule.  On top of that there are a
bunch of optional features (bignums, various database plugins, etc.)
That's a lot of build-and-test cycles to cover all the code paths.

I told you this is a leprous codebase.

 > as opposed to "remember this constantly changing list of things to
 > check."

They typically don't do that, either.  It's not like we don't have
"make check" (a 15-year old feature descended from the original Lucid
code) but people often resist running tests that take longer to run
than either writing the patch or rebuilding XEmacs did.  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.

 > Err...yeah. But I don't see how this changes anything; they could have
 > done exactly the same if you were using svn.

Not really.  Many of the occasional developers I'm talking about never
had commit privileges in CVS, and even those who did generally were
unwilling to create branches, preferring to keep private workspaces
and generating patches from those against CVS.  I never understood
why, but the attitude was "branches are unusable in CVS."

 > > In the case of XEmacs (or Linux, see Shawn Brown's recent post), the
 > > first step is "clean up thousands of lines of existing code".
 > 
 > I don't think so. If you have two feature branches that have diverged
 > and you want to merge them,

I'm confused.  I thought the "first step" we are taking here is toward
CI.  I know how to merge feature branches, and it has nothing to do with:

 > the first step is actually just move both copies to the same
 > branch, and build both from their entirely separate sources. Then
 > you can start picking off the parts that are easy to merge (such as
 > the source files that are exactly the same) and putting them in a
 > common area, and move on from there.

because any decent VCS already does that for you.  For example, it is
occasionally the case that when two files are exactly the same across
two FBs, one of them is buggy.  (That developer missed fixing a call.)

 > I think I mostly disagree with the way things are presented: I'm hearing
 > "cheap branching is good," and "you should be using feature branches
 > under most circumstances,"

I do believe "cheap branching is good", but I don't believe "you
should be using feature branches under most circumstances."  And of
course "cheap merging" would be better than anything!

 > My imagination does scale to working on a "positively leprous" project
 > like an Emacs. If I started hacking on XEmacs, for example, I'd probably
 > start out by doing a lot of the things you are doing, and doing a lot
 > of them the same way for quite some time. I'd just call those things
 > "compromises" rather than "solutions."

When "quite some time" starts to stretch into decades, you start
looking for euphemisms, though.