Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Open-source repository question



Curt Sampson writes:

 > So it looks as if Martin Fowler is on my side, here:
 > 
 >   http://martinfowler.com/bliki/FeatureBranch.html

Not really.  He's describing conditions where anybody with half a
brain would admit CI will work: a disciplined (small) team working
intensively on a project with a rather clean codebase.  The whole
section "PI vs. CI" is far more supportive of of feature branching,
especially as the strawman problems of PI that he sets up he ends up
knocking down himself.  Nevertheless, he lets his prejudices draw the
conclusion.

My observation of open source projects (specifically Emacs, XEmacs,
Mailman, Python, and many small plugins for those projects) is that
while Fowler's observation that "With a less disciplined team I would
worry that a DVCS would nudge people towards long lived branches" is
correct, 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.

Fowler also observes "I much prefer designing the software in such a
way that makes it easy to enable or disable features through
configuration changes" to dealing with feature branches.  Well, of
course; who wouldn't?  The problem is that runtime configuration
changes are risky or inefficient in something the is supposed to
provide a stable platform for other applications, such as an OS kernel
or an IDE like Emacs.  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.

Note that I do not claim these are universal tendencies; I am sure
they are not.  But they do apply, empirically, to the projects whose
inner workings I am most familiar with.


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links