I never had a chance to fully pipe into this discussion esp from the
QA point of view.
During the on-site week, I finally had the opportunity to speak with
a few of
you about Chandler testability. This was particularly for me to
understand why this was such a difficult problem to solve. After
understanding the layering of the components (or the lack of) in our
architecture, I
came to understand a lot of the issues already being discussed on the
list.
I believe the consensus across board was that the way we were
structured currently, with our monolithic architecture, we couldn't
achieve much testability without some sort of
restructuring or refactoring. Now, this is specifically for vast
majority of tests we want to add to
test the application logic without going thru the UI . John's
record/scripting framework
will help us with tackle the UI level tests.
Some ideas that followed from the discussions were:
1. While we are doing shorter release cycles, not all developers may
have bugs to fix in each release. Those who have the time
afforfance could start some simplified refactoring work of their own
components in the branches.
2. A few developers can work on the refactoring project, for e.g. say
replacing CPIA, while most other devs focus on the incremental bug
fixes and small features that users are asking for
Though it is easy to swing in extremes, from doing nothing at all to
doing a mass Chandler rearchitecturing project, I would like to hear if
there is any middle ground that can be achieved.
Apart from the larger goals of sustainable code base etc, this is
specially
important for making shorter release cycles successful without the
unattainable effort of
manually going thru 13 test specs and some 1200+ testcases for each
release cycle.
Aparna
On Oct 8, 2007, at 8:24 AM, Grant Baillie wrote:
Since there have been around 80-odd messages on chandler-dev@ on
the subjects of architecture, testability, and What Do We Do Next,
it seemed like a plan to try to summarize the story so far. I've
kind of grouped things under several themes; hopefully this will be.
In the summary below, the *Agreement* parts indicate, roughly, 2-3
or more people concurring without any significant disagreement. If
you feel your dissent has been ignored, or you didn't register it,
feel free to say so.
There are also a couple of topics I'm explicitly not covering,
since they have already become (recent) history:
* 0.7.1 feature set and timing
* frequent releases
Overall direction and requirements for the project
--------------------------------------------------
Katie's original email stated the next goal as being "to build a
user base and a working community".
*Open Issues*: At the time was what, specifically, this means. E.g.
how do we prioritize courting users vs developers, or short-term
bug fixes and feature work vs longer-term rearchitecture. More
generally, the issue of making the project sustainable (i.e.
finding revenue opportunities, or building a developer community to
maintain Chandler in the long-term) came up.
Prioritization issues are covered by Katie's recent email:
http://tinyurl.com/2eph43
Also, for PPD's take on what they would like addressed, see Mimi's
design list posting:
http://tinyurl.com/ypq5hn
Rearchitecture vs End-User Feature Development
----------------------------------------------
There was some concern (e.g. from Brian K, John, Andi) that a major
rearchitecture/rewrite will time away from developing end-user
features, and fixing bugs that impact end-users (i.e. being
responsive to our users). This would in turn hinder adoption, which
could have disastrous consequences for the project.
*Agreement*: Having everyone "drop tools" to work on rearchitecture
(i.e. longer-term goals) would not be good.
*Agreement*: There was some support (Jeffrey, Morgen, PJE, Heikki,
John) for having a smaller group attack architecture on the side,
possibly starting out with CPIA. PJE pointed out that this could be
done similarly to previous work of his at OSAF (schema API and
EIM), where a couple of developers were involved initially, before
others moved over to the new architecture as needed.
*Agreement*: (PJE, Paul) Focusing only on getting end-users will
not be enough to make the project sustainable once funding expires.
Testability
-----------
PJE: Testability is a requirement for the goals laid out in Katie's
original email, and is therefore a "wedge issue" for the whole
discussion. Testability is also necessary to build a developer
community.
Morgen: Testability has been vital for development and ongoing
maintenance and feature development of syncing code.
Heikki: Testability has not been a requirement in the development
of a well-known family of open source web browers whose process he
happens to be familiar with.
There was some discussion of testability in the thread following
Aparna's "Desktop Test Automation Project" email. In the standard
layered approach, we could tackle testability of presentation layer
code with a mock wx.
Architecture and goals
----------------------
PJE's desirable architecture: (i.e. separated layers, for
testability and pluggability) is the old spike project he did a
couple of years back. (Some of these ideas have since been
incorporated into Chandler):
http://svn.osafoundation.org/chandler/trunk/internal/Spike/src/
spike/overview.txt
PJE's 3 architecture process options, quoted:
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
The first minimizes upfront costs (rearchitecture) vs less apparent
later costs (time to stabilize releases).
Andi, John, Heikki: Favour incremental vs more radical architecture
changes.
CPIA/Persistence in the UI
--------------------------
Katie's original email suggested that we shouldn't be persisting so
much of the UI structure of the app. John noted that transparent
persistence was a refreshing contrast to other systems he'd worked
on, where you had to write SQL queries every time you needed to
persist something. Philippe pointed out that having everything be
persistent is confusing for new developers: it's hard to make sense
of all the attributes that get tied to even simple items when
displayed in the UI.
PJE: What we need is to separate out visual presentation (not
persistent) from application logic (e.g. which items are selected
in which collections, etc). That leads to greater testability (you
can test the application logic without the UI). Ideally, you could
separate out persistence as well, which means you can run tests of
the application without the repository. Greater separation means
more opportunity for parallel development (i.e. of views vs
interaction model vs persistence) of features.
*Agreement* (Philippe, PJE, Reid, Andi, John, Mikeal): Cleaner
separation of UI from the rest of the app.
*Agreement*: (Philippe, PJE, Andi): Not persisting redundant/
constant UI data.
*Agreement* (John, PJE): The current template mechanism in Blocks
is confusing and mostly a historical artifact, so it should be
removed.
Performance, Scalability
------------------------
*Open Issue*: (Grant, Andi, Brian K) Unclear what the goals are
w.r.t. email beyond what we have today. Need measurements of how
Chandler performs in the presence of many items (and/or
collections), as well as explicit performance goals.
Timing of 1.0 Release
---------------------
Davor: Shouldn't a "1.0" release happen pretty soon (a few months)
after a "0.7"?
Piero: Not necessarily (depends on what needs to be addressed).
Project needs some kind of a roadmap.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
