Re: [tlug] Open-source repository question

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

Curt Sampson writes:

 > I'm not sure how statements such as, "On the whole, however, I don't
 > think cherry-picking with the VCS is a good idea" can be interpreted as
 > supportive of feature branching

It's not.  My point is that the things that he explicitly says are bad
about feature branching he then acknowledges aren't a problem in
practice (eg, textual conflicts), so in context the statement you
quote has the semantic content "cherry-picking isn't CI so it's not a
good idea".  Effectively, NIH => bad.

I'm sure he justifies that elsewhere, but investigating that costs
more than the time I have at the moment.

 > > "...it is also a necessary corrective to the greed of the average
 > > developer for getting his patches into the mainline, and let those who
 > > commit afterward deal with conflicts with his ill-thought-out patches.
 > 
 > I'll buy this. I will not buy the idea that the "greed of the average
 > developer" you describe above is a good thing, and that it's not a
 > problem we should try to fix at the root.

I don't claim it's a good thing.  I'm somewhat disliked in the XEmacs
community for saying it's a bad thing, in fact.  But the only way to
fix it at the root is to exclude them from the team.  That's sort of
antithetical to the idea of a public project.  The alternative is to
reject those patches until acceptable, which is a feature branch.  No?

 > > Build-time configuration changes, when builds are expensive, lead to
 > > situations where only a small subset of the integration problems are
 > > actually noticed in many cases.
 > 
 > I can quite easily think of ways to notice more problems with build-time
 > configuration changes; I'm sure you can, too.

Sure.  "Jesus FUCKING Christ, if you can't run a build configured
--with-gtk before committing code that changes the GUI abstraction,
DON'T FUCKING COMMIT, OK!!!!!!"  That normally causes the listener to
go away, rather than start doing appropriate testing.  With DVCS
s/FUCKING//g and s/COMMIT/push/g, they don't go away, but they do end
up on a feature branch.

 > Shared-a-little-bit is still better than shared-nothing, and also makes
 > it considerably easier to move to shared-a-little-bit-more. It's the
 > first step that's the hardest here.

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".  Damn
straight that's hard!<wink>  To put it in "shared" terminology, it is
not possible to share with programmers who are disappeared and
possibly hostile or dead, and for many lines of code, not even
singular.  Much code in XEmacs "speaks with forked tongue" as it were.

 > I'm familiar with these. I just think that using branching to attempt to
 > paper over the real problems, and otherwise giving up on solving them,
 > is not the proper long-term fix.

I agree, FVO "long-term" = geological time scale.<wink>

BTW, it occurs to me that one source of our apparent disagreements (as
opposed to our real disagreements) is blanket claims by me and Josh
that CI and related forms of coordination advocated in certain Agile
circles "don't scale" (ie, "not ever").  But then we[1] have unfairly
interpreted you as saying "these Agile practices constitute a panacea"
when your real claim is "they do too scale to anything I have worked
on or can imagine working on".  Two questions: (1) Do you think that's
a fair statement of the situation?  (2) Does your "imagination" scale
to working on a somewhat unclean, homongous project like the Linux
kernel, or a positively leprous, moderate-sized project like an Emacs?

Footnotes: 
[1]  I think I'm justified in speaking on Josh's behalf here, but
before anyone takes him to task, check first.