Build, release and QA
---------------------
*Nominating bugs for alpha3*
I proposed that the process for nominating a bug for alpha3 should be to
change the target milestone to '---'. Bugcouncil's process is to review
untargeted bugs regularly and assign them to a release. Mikeal suggested
that this should be the process for bringing a bug to bugcouncil's
attention for any reason, at any stage of the release cycle.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006245.html
*Adding check() to functional test suite*
Mikeal pointed out that CATS 0.2 will have a "debug level". We could use
this as an option to RunChandler, where check() gets run after every
test for certain debug levels. Implementing this will be easy with the
new framework. We are a few days from being at 0 bugs in CATS 0.2, so
perhaps wait on this before adding check() to each test script.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006246.html
*Cats 0.2*
Mikeal announced that we're near completion of CATS 0.2, which is a step
towards the upcoming Open Automation Framework. We'd like to increase
the stability and ease of test writing, and make the transition to OAF
more seamless. Mikeal has written a general doc and a guide to test
writing. Additionally, the source is well commented. Note that
QAUITestAppLib has been renamed to ChandlerTestLib. Mikeal gave links to
the source and the ported tests. Feedback welcome, Dan Steinicke will be
the point of contact for CATS.
http://wiki.osafoundation.org/bin/view/Projects/ChandlerAutomatedTestSystemZeroPointTwo
http://wiki.osafoundation.org/bin/view/Projects/WritingChandlerAutomatedTestsWithCATSZeroPointTwo
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006247.html
*Checkpoint build*
Dan gave the report for the checkpoint build:
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006260.html
*Alpha3 branch*
We got under the 10 code change bug mark (8) on Thurs, July 6. Heikki
moved the target milestone to alpha4 for all test related bugs. Next
Monday's checkpoint build will be on the branch only.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006262.html
Bear created a branch, the trunk is open for alpha4 work. The alpha3
branch is restricted -- only commits with bugcouncil approved bugs and
code review.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006263.html
*GCJ upgraded on Windows*
Andi upgraded gcj on Windows to fix a bug (6072). "make compilers" is
required if you are doing full builds on Windows.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006270.html
Bear noted that the compiler tarball is compressed using bzip2 and that
GCJ_HOME/GCJ_VER need to be set as a pair (unless you let the makefile
handle it).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006271.html
Interns and SoC projects
------------------------
*Contacts/Address Book*
Ernesto modified his plan based on feedback; conforming to vCard will be
his first task, then import/export to vCard. Dynamic detail views ala
OSX's address book will be a bigger challenge than the schema: the
display/editor for creating an arbitrary number of fields, and the
display/editor for tagging each field (home, work, etc.). Ernesto asked
for examples in Chandler. Ernesto explained that he was thinking about a
"see everything related to this contact popup" to display links. He
pointed out that contacts already have bidirectional links to other
items. In response to Ted's question about propagation, Ernesto
explained that some actions might apply to the group as an item (e.g.
add group to office hour event), but other actions apply to each item
in the group (e.g. sending an email to all members of the group).
Ernesto explained that ContactPerson and ContactGroup are currently both
subclasses of an abstract Contact superclass. It might work to make
groups collections, but raises questions: allow non-contact items to be
added to the collection? any collection can become a group if it
contains a contact? Also, adding groups to the sidebar or requiring them
to live there won't be practical.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006236.html
Bryan observed that Ernesto might want arbitrary sets of repeating
blocks (e.g. a value editor and a label editor for each of several email
addresses.) The detail view currently only supports fixed sets of blocks
for a particular Kind. Bryan suggests starting with a detail view that
only displays one; once that is working he can help expand it.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006237.html
Ernesto asked if there was a table view, and gave a screenshot of a
possible UI. Grant and Bryan agreed that a table widget would be a way
around the current detail view limitations. They both pointed out that
the limitation is the current detail view block architecture, not wx.
Grant gave pointers to Table.py and code that makes use of it. Grant
also suggested writing unit tests for vCard import with sample data, he
offered help in setting that up.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006239.html
John suggested the architecture could support a variable number of
fields by changing the method on the detail view's BranchPointBlock that
returns a tree of blocks. He questioned if this work would be consistent
with Chandler's design. He also noted that going down this path will
likely require some working out of snags. Ted responded that Ernesto
will be working with Mimi on UI review, so the design they work out
should be consistent with the Chandler design.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006242.html
Bryan gave more details about a question Ernesto asked in IRC: how to
display ContactGroup.countMembers() in the detail view. Bryan suggested
creating a Calculated attribute around the countMembers() method; this
adds type info that guides the attribute-editor picking mechanism. He
also gave details on how to hook up to StaticStringAttributeEditor. He
noted that it might not do the right thing for numeric attributes, so a
tweak or a different attribute editor might be needed.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006243.html
*Chandler IMAP server parcel*
Travis sent out his IMAP server parcel. IMAP mail clients should be able
to "see" Chandler, and enable the user to drag email into Chandler. The
README.txt has instructions on how to set this up in Mail.app and
Thunderbird -- the parcel has been tested on these clients. Testing on
Outlook welcome. Travis asked for a review on his use of the repository
APIs -- he marked specific questions in the code with #XXX. He'll have a
subversion sandbox setup soon.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006248.html
Excited about the IMAP parcel working, Mimi asked questions about
additional features to flush out the workflow. How smart is Chandler
when an email is dragged into its repository? Can Chandler: (1) identify
that an email was sent from Chandler and reconstruct the (stamped) item
from the email? (2) Identify an email was sent from Chandler and that
the email is really the same item as an item already in the repository?
(3) Identify an email was sent from Chandler and is really an update to
an item you already have in your repository?
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006249.html
Andi reviewed Travis' parcel:
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006268.html
Dev projects
------------
*Reminders when Chandler GUI is not visible*
Grant started a discussion about how to implement the feature of giving
the user reminders even when the Chandler UI is not up and running (Bug
5407). He noted platform specific differences, and asked for input on
non-mac OS-specific services. How do we get a background process running
whenever the user is logged in? On the mac, you can add a background app
to the user's list of login items; launchd may be an option in Tiger. Is
the Windows Service facility the right approach? Linux? Grant described
4 options from there: (1) Two separate processes, app and service, both
accessing the repository. (2) Two processes, but the background daemon
doesn't talk to the repository -- use named pipes or a file or some
other variant. (3) Have two processes, but do a handshake at launch/quit
-- only one is responsible for displaying reminders at any given time.
(4) Have one process, but add ability to switch between full UI and
background mode.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006250.html
PJE suggested using the OS's scheduling facilities to run things when
they are actually scheduled. The program wouldn't need to run all the
time. Alternatively, run something like a sleep command followed by a
notifier for low resource usage. Windows also has a notion of "startup
entries" -- not sure if services launch at login. For option #2, PJE
suggested XML-RPC. Alternatively, dump reminder files in a directory.
You have to get some details right wrt naming files, deleting files and
processing changes -- think of the directory as a message queue, not a
database. The approach is robust -- no locking issues, nothing
corrupted, no platform differences.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006251.html
Bear also discussed the flat file idea, any low impact program could sit
in the task tray/status bar, run through its paces and then go to sleep.
The notification process could be OS specific: Growl for OSX, Popup
dialog for Windows, etc. The program could detect Chandler and
communicate with it for other value added services. Bear noted that each
OS provides an area for programs that get started when the user logs
into the system.
Andi explained that (1) would work. Andi explained that repository files
must be stored on a file system that supports proper locks. Berkeley DB
supports multiple processes accessing the repository as well as multiple
threads. Andi suggested that multiple processes, one for each task,
seems cleaner.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006254.html
*Repository documentation*
Ted asked Andi if his EuroPython slides would be a good starting point,
if they included some of the content Heikki asked for. Andi sent a link
to the slides. As a starting point he will add some posts to the
chandlerdb blog answering specific questions from Markku, starting with
code structure and organization.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006257.html
*Sharing, information model, dump/reload*
PJE brought a conversation with Morgen about the sharing format to the
list. Morgen asked about using Google's Data API for sharing (an
extension of Atom), offering an interop advantage. PJE pointed out that
it doesn't really have a uniform, elementary information model. He gave
gd:recurrence as an example, which embeds vobject in the XML model. PJE
explained that the Chandler information model can be described as a
meta-schema defining what schema we can express in Chandler. Elaborating
on "elementary information model", PJE argued that its useful to have a
simpler model that can express the same ideas for an exchange format,
for dump/reload, etc. A simpler model can be more robust in the face of
upgradeability and data interchange. The information model is
representation-independent, and can be expressed in XML, Python pickles,
etc.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006258.html
Morgen gave RDF as an example of an information model (a graph data
model that can be expressed in RDF-XML or N3). Phillip explained that
having an explicitly specified information model allows systems
supporting that model to guarantee what is supported storing, querying,
and retrieving, separate from the representation format. The stack: (1)
Application/domain model, (2) information model, (3) representation
format. Parcel developers will have to define a mapping from the domain
model to the information model. The information model must remain stable
(only added to). Multiple representation formats are possible, and the
domain model can evolve over time. The mapping between 1 and 2 could be
considered a layer in and of itself. PJE noted that defining the API
around the information model is an interesting problem. He's been
thinking about dump and reload -- the sharing use cases have different
demands. Sharing involves incremental modifications to items, and
dump/reload only cares about changes to the information model, where
sharing cares about domain model changes.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006266.html
Morgen summarized where we're at wrt the sharing format on a wiki page,
which lists requirements and outlines the proposals that have been made
so far. The discussion will continue on the cosmo-dev mailing list.
http://wiki.osafoundation.org/bin/view/Projects/SharingFormatDiscussion
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006259.html
*i18n*
Brian K sent out demo code with 3 egg projects: python code +
localizations, only localizations, localization files for a project in
another egg. The external API might change but the examples give a good
idea of how things will work.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006261.html
Self assigned projects
----------------------
*M2Crypto*
Heikki released M2Crypto 0.16 on Wednesday, July 5. This was a
significant release: it fixed all known regressions and memory leaks,
and integrated new features from other developers. He also added i18n
support, which we'll be needing in Chandler. 0.16 has already been added
to the Fedora Core package system. Heikki also included some comments
from happy users.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006265.html
Meetings and announcements
--------------------------
*Wiki spam changes*
IT installed a plugin to combat the increase in wiki spam (a source of
wiki slowness). Let Bear know if you have problems adding or editing
content.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006267.html
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
