There have been a lot of postings on this thread (yay), some of which
I'll still be replying to. I'm picking Mimi's because it's somewhat
high level. At a high-level, there are two questions I see here:
A) What to do when
==================
1) Don't rearchitect anything: just fix bugs, incrementally add
features, except for the ones that are impossible (I'm thinking
mainly scaling to real-world email volume), until the end of 2008.
2) Attempt to develop in parallel: i.e. have some fraction of the
team work on adding relatively low-impact and desirable features,
like scripting, printing and month view, so that there are
appreciable signs of progress for end users.
3) Bite the bullet and rearchitect (whatever that means -- see below)
now, taking the position that this way we'll be better placed to Give
Users What They Want.
B) What does "rearchitecture" mean?
===================================
This is the question (or presentation of options) raised by PJE early
on in the thread:
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
I should point out that it is a good idea to bear in mind approaches
that have been known to work elsewhere (i.e. things like Model-View-
Presenter or Model-View-Controller).
In addition, keeping performance and scalability in mind. I have had
in the past heard a description of the existing architecture (by a
Chandler developer) start out with "Assume an infinitely fast and
scalable repository ...", which needless to say puts somewhat hard-to-
satisfy requirements on the repository :o.
Anyway, my point is mainly to separate out the two issues. I'll
clarify (hopefully) a little more about B1-3 in some subsequent emails.
--Grant
On 6 Sep, 2007, at 17:00, Mimi Yin wrote:
I wonder if this is too stark a way to frame the situation.
I think we all want Chandler-the-code to be easy to maintain.
*And* we all want to have users for Chandler-the-product so that
Chandler-the-code will be worth maintaining.
(I think the concern people have is that without a real user-base,
no one will bother to maintain / add onto Chandler, even if it's
the easiest code to work with in the world.)
The question in my mind is more: How should we balance
rearchitecture with user-driven improvements to Chandler-the-product?
I'm about to post a response to this thread on the design list
which hopefully addresses this very issue. Looking at the bug list,
deferred feature list and user feedback, I'm not sure we need to
decide between users (features) and code (rearchitecture). I'm
hoping we can be responsive to users with a 'FIX WHAT'S BROKEN'
approach and defer major feature work until after 1.0. Anyway, I
will leave you to read the design list email for a more coherent
framing.
Mimi
On Sep 6, 2007, at 4:20 PM, Phillip J. Eby wrote:
That having been said, I don't have as much invested in Chandler
as I did in either of those projects. The first I was a minority
shareholder in the company, and for the second I was creator/
auteur and project manager. On Chandler I'm just "hired help", so
it's not my money and it's not my vision. But I'd *still* like to
see it around 5 years from now, and from that perspective I don't
see the end-of-'08 functional requirements being nearly as
important as non-functional requirements like performance and
maintainability.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
