[Chandler-dev] What is next for Chandler desktop?

[Phillip J. Eby]

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?