At 04:33 PM 9/5/2007 -0700, Bryan Stearns wrote:
Phillip,
I'm unclear on what the goal behind these options is: the only goal
I see you mention is getting test coverage.
That's because Katie sufficiently covered the other goals in her
post, and testability is a critical part of the means towards those
ends, because we aren't going to be able to make significant changes
to the parts of the system that need changing, so long as the parts
that use them can't be independently tested.
I guess Katie and Grant and I have been talking about these issues
for so long now that we may forget that some of the connections
aren't necessarily apparent at first glance. My apologies for not
clarifying the context.
Are we considering starting Chandler Desktop from scratch
No. A port/refactoring to deal with the collections, persistence,
performance, and event management issues is hardly the same thing as
starting from scratch.
But I don't want us to get bogged down in a detailed discussion of
those issues, if this one "wedge" issue will suffice to set the direction.
I would much rather we all get crystal clear on this one issue, than
on all the others put together, because it has far more impact on the
project's long-term direction and probability of success than all the
others put together.
for just that reason alone?
That depends on our goals for the project. If we see our purpose as
to deliver a certain feature set, after which time the project will
no longer effectively grow or be maintained, then it may well be
reasonable to continue along the current path.
If Chandler is to become a community-supported project, on the other
hand, the status quo isn't going to keep working when OSAF is no
longer funded at the current levels. New development will likely
grind to a halt, and plugin development is unlikely to take off.
So all I want to point out, is that there is a choice to be made
between these two paths. I'm highlighting testability because I
don't believe it's possible to achieve long-term viability without
it, barring the sudden appearance of another funding source.
So there's little reason, IMO, to dig into other questions about the
architecture. Testability is enough to make or break the project,
and either we collectively believe that, or we don't. The rest of
the decision(s) will follow smoothly from that.
I don't personally have a vested interest in either direction,
however, because it ultimately doesn't matter to me whether Chandler
survives as a community-supported project. It'd be nice, and I'd
like to see that happen, but that doesn't mean OSAF as an
organization has the same goal or agrees that this is the way to make
it happen.
I *do*, however, have a vested interest in us having a 100% clear and
unequivocal decision about which direction we're taking. I don't
want us to pay lip service to testability while actually making
features paramount. Nor do I want to see us go the refactoring
route, on the other hand, if we don't really have the stomach to see
it through. Both routes would lead to unnecessary stress and work
for everybody involved.
So an unmade, default/de facto decision to "focus our efforts across
the board" is really no decision at all, and hurts everybody. We get
all the costs of making a decision, but none of the benefits of
certainty or clarity of focus that comes from deciding what the
actual priorities are.
That's why I'm writing so much here in response to your brief
question: the question presupposed that there was nothing to
decide. But it's far too important of a decision to be made by
default, even if we end up explicitly choosing the default. Make sense?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
