Phillip,
I'm all for the idea of improving testability of Chandler - I just don't
have a picture in my head of what form that would take, nor do I
understand what process you're suggesting we use to get there.
It sounds like you have a clearer picture than the rest of us about what
specific architectural problems we need to refactor away, and how you
think we should do it. I'm looking forward to more details from you and
Grant.
...Bryan
Phillip J. Eby wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
