At 02:05 PM 9/5/2007 -0700, Katie Capps Parlante wrote:
Phillip Eby and Grant have been exploring some options (at my request),
I'll let them introduce that work.
Broadly speaking, there are three options regarding the architecture:
1. Start with the current architecture and evolve it in-place
2. Define a new architecture in terms of "off-the-shelf" Python components
3. Develop an architecture specifically to suit Chandler's current goals
Each of these approaches has trade-offs. #1 is heavily burdened by
inertia in the long run, and has a high risk of not being able to
meet future goals, but is extremely attractive (even addictive) in
the short run due to the "high" of being able to get more features
quickly, at the cost of later "hangovers" at release time.
That doesn't mean it's necessarily the wrong choice. It's certainly
a valid (if risky) choice to leave things as they are, and say,
"we'll fix it when (if) we have funding".
The other two approaches carry a significant up-front cost: "porting"
existing code to a new architecture. But the immediate trade-off is
that every bit of code ported can be verified as covered by automated
tests, and the other issues can be resolved.
To a certain extent, these approaches *appear* riskier because there
is a definite up-front cost, and the human brain is biased towards
options that lead to a sure short-term gain and a possible later
loss, over options with a sure up-front cost, for a possible later
gain -- even if the two options are mathematically indistinguishable
in terms of net gain or loss!
So it tends to come down to the question of what kind of delays we'd
prefer: relatively predictable up-front delays, or release-time
delays of unpredictable duration?
This might seem like rigging the question -- after all, it's not
possible to 100% rule out release-time problems from a new architecture.
Or is it?
If the issue is adequate test coverage (and having a test-driven
development culture), then I think we *can* have a considerably more
predictable release cycle. In a test-driven model, the architecture
is forced to be modular (and acyclic!) in ways that we currently aren't.
Ultimately, this is a "bet the farm" decision, and all choices are
equally risky in the sense that the wrong one will sink the
project. The major advantage of option #1 is that its failure mode
doesn't carry any *personal* risk to the individuals involved.
That is, in the "nobody got fired for buying IBM" sense, it makes
sense for *everybody* involved (me included) to CYA by recommending
option #1. If it fails, nobody can point a finger at any of us --
especially since the most likely form of failure is just that the
project just fades slowly into obscurity.
To choose option #2 or #3 is to open one's self to possible ridicule;
every setback, however minor, may be used by the ignorant as an
excuse to attack the decision.
For that reason, I do not suggest that we take option #2 or #3 unless
there is a 100% commitment to a test-driven culture from everyone
involved. Without that, we'll be taking all the risks of a port
without gaining the benefit of a 100%-coverage, fully-vetted codebase.
But without that test coverage, Chandler as a project will be on life
support. It's not reasonable to expect that volunteer maintainers
are going to step up and match the amount of build and QA
infrastructure that OSAF currently has, to work around the current
level of testability.
So, I think we need to be clear about what path we're choosing, and I
think that detailed proposals are actually beside the point at the
moment. If we *want* a test-driven Chandler, we can have it. (And
we may not even have to give up that many features to get it!)
But we should answer that question first, and *then* worry about the
how. Otherwise, it's all too easy to delude ourselves into thinking
that we're making the right choice because there weren't any viable
proposals for anything else (because none of them will be *perfect*),
thereby avoiding the tough choice of what it is we actually want, and why.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
