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

[Bryan Stearns]

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