[Dev] Status Update #10
Pieter Hartsook
hartsook at osafoundation.org
Mon Oct 27 18:26:40 PST 2003
(to see the formatted version of this Status Update go to:
http://wiki.osafoundation.org/bin/view/Main/UpdateNumber10 )
Status Update Number 10 – October 27, 2003
==========================================
Recent new or updated wiki pages of note:
------------------------------------------------------
To keep track of where the action is at OSAF you may want to check the
most frequently accessed Wiki pages, see what topics are viewed most
often and who is contributing new material.
http://wiki.osafoundation.org/bin/view/Main/WebStatistics
============================================================================================
Chandler Design and Development - (Release Information, Chandler
Components, Miscellaneous)
============================================================================================
Chandler Release Information
* The current release - is 0.2 (see the 0.2 Release Post-Mortem below)
* The next scheduled "dot" release - is scheduled February 2004. Check
with the Chandler Timeline Wiki page for updates.
http://wiki.osafoundation.org/bin/view/Main/ChandlerTimeline
* Milestone releases - are calendar-based. For a schedule of the release
dates leading up to 0.3 and a summary of open "bugs" and "To Dos" you
can review our progress on a Buglist summary for 0.3 Page
http://bugzilla.osafoundation.org/michael/milestone.cgi
* Latest builds - If you are a developer and can't wait for a milestone
release you can of course visit the Chandler developer download pages
for interim builds.
http://wiki.osafoundation.org/bin/view/Main/GettingChandler#developer
---------------------------------------------------------------------------------
Chandler Components (Capplets, Frameworks, and Meta Issues)
---------------------------------------------------------------------------------
Feature Prioritization - thoughts from Chandler's Product Manager, Chao
Lam, OSAF's Product Manager is spending a lot of his time right now on
feature prioritization.
"Everyone has great ideas about what needs to be in the product,
especially Mitch! But if we're going to keep on schedule and ship a
product at the end of 2004, deciding what to leave out of version 1.0 is
as important as deciding what to put in.", commented Chao at a recent
meeting. "We want to have sufficient core functionality to enable people
to use it in daily work, but we also want to include at least some cool
new features that will distinguish Chandler from other products in the
PIM space. So in addition to the ongoing infrastructure work on our Data
Model and Data Architecture we are trying to plan what sets of features
to implement at each point along our RoadMap Timeline."
-------------------------------------------------------------------
Table of Contents
Chandler Components - Capplets (Chandler Applets)
-------------------------------------------------------------------
1. Email
2. Calendar
3. Contacts
4. Todos/task/notes
5. Instant Messaging
-------------------------------------------------------------------
1. Email Features -- Ducky has been working on a better definition of
the e-mail functions in Chandler. To see the latest thinking in this
area see the following Wiki pages:
* E-mail Project Table of Contents Page - This area is designed to be
the focal point for all things related to Chandler's Email parcel.
http://wiki.osafoundation.org/bin/view/Main/EmailProject
* Debatable E-mail Feature Set
http://wiki.osafoundation.org/bin/view/Main/DebatableEmailFeatureSet
* Intrinsic IMAP Issues - There are a few issues relating to IMAP's UI
that are constrained by inherent features in the IMAP protocol and
others which are probably just the client doing a poor implementation.
This page will describe some of the issues intrinsic to IMAP.
http://wiki.osafoundation.org/bin/view/Main/IntrinsicIMAPIssues
2. Calendar: -- Katie has developed and collecedt materials on the
calendar functionality in Chandler.
* Calendar Project Page covers calendar related functionality in
Chandler, including the Calendar documents, time/calendar blocks/widgets
available in the document architecture, and the calendar related schema
in the core PIM schema.
* Calendar Feature List prioritizes calendar features and identifies
release targets feature-by-feature.
http://wiki.osafoundation.org/bin/view/Main/CalendarFeatureList
3. Contacts - no major activity this report
4. Todos/task/notes - no major activity this report
5. Instant Messaging no major activity this report
-------------------------------------------------------------------
Table of Contents
Chandler Components - Frameworks
-------------------------------------------------------------------
1. Chandler Presentation and Interaction Architecture (CPIA)
2. Agent Framework
3. Parcel Framework
4. Data Framework
... -- Database and Repository
5. Sharing/Discovery Framework
-------------------------------------------------------------------
1. Chandler Presentation and Interaction Architecture (CPIA)
* This document
(http://wiki.osafoundation.org/bin/view/Main/ChandlerPresentationAndInteractionArchitecture)
describes the Chandler Presentation and Interaction Architecture (CPIA)
-- the way that Chandler displays information on the screen and accepts
input from the user.
2. Agent Framework - Stuart Parmenter, one of OSAF's latest engineers,
has begun working with Andy Hertzfeld on the agent framework.
http://wiki.osafoundation.org/bin/view/Main/UpdateNumber10#NewHires
3. Parcel Framework
* Threading Summary: - At the end of the 0.1 release, we noted threading
issues as a possible snake. This page notes where we stand as we start
work on the 0.3 release. Notes on Threading.
http://wiki.osafoundation.org/bin/view/Main/NotesOnThreading
4. Data Framework
* XML schema loading: - Checked in the new general loader. It loads the
calendar file (with some tweaks), and it loads general items. Still
requires more testing, as well as minor changes as we resolve open issues.
* Database and Repository:
+ ZODB: - John finished removing ZODB from Chandler, except where
features of the repository make it impractical.
+ BerkeleyDB: - Andi finished on-demand loading for references and
started using BerkeleyDB transactions around Repository.commit().
* Data Model Project - Home Page - The goal of the Data Model Project is
to design and build some data handling infrastructure for Chandler.
http://wiki.osafoundation.org/bin/view/Main/DataModel
* Data Model Status, Sept. 2003, Rel. 0.2 - The 0.2 release includes a
number of new components for handling Chandler data: tools for
describing data, storing data, and viewing data.
http://wiki.osafoundation.org/bin/view/Main/DataModelSept2003Status
* Data Model Developer Guide - is intended for Chandler developers or
people otherwise interested in the design decisions and API
implementation of the front-end to the Chandler persistence layer.
http://wiki.osafoundation.org/bin/view/Main/DataModelDevGuide
* Data Model FAQ - a list of questions asked by developers new to the
Data Model and Repository APIs.
http://wiki.osafoundation.org/bin/view/Main/DataModelFAQ
5. Sharing/Discovery Framework - no major activity this report
-------------------------------------------------------------------
Table of Contents
Chandler Components - Meta Issues
-------------------------------------------------------------------
1. UI Design
2. Build Issues
4. Installer
5. QA
6. Ecosystem
-------------------------------------------------------------------
1. UI Design - Mimi Yin
(http://wiki.osafoundation.org/bin/view/Main/UpdateNumber10#NewHires)
has recently joined the OSAF staff as our UI designer. She has begun the
task of understanding Chandler functionality and attempting to map it to
various UI designs.
2. Build Issues - Morgen has been working on improving the build
experience. Debug and Release coexistence project was completed, the
ability to have debug and release builds live side-by-side without
having to "clean" whenever you switch between them, plus "clean" should
work now too. Notes:
* For distutils-based projects, I now pass a BUILD_BASE parameter
* For configure & make projects, most honor the Makefile VPATH trick
* Modified Xerces to create "phantom" build directories by making copies
of the source directory structure and creating symlinks to the source
files. The Xerces build system doesn't realize that it isn't actually in
the real source directories, and I can coerce it to build in separate
directories now.
* Start with a fresh checkout or at least do a hardhat scrub (if you
know what you are doing) to make sure that you don't have old build
directories lying around and that you have all the latest _ _ hardhat _
_.py files -- most of them were changed.
* For fun, build debug and release at the same time with "hardhat.py -BdB"
3. Tools
* Bonsai is up and running -- Heikki has "finally got this thing
running", with one caveat - checkins during the last couple of days
prior to 10/24/2003 do not show up (Heikki will need to recreate the
database to do that, but suggests "let's just run for a while and see
how this works").
* Bonsai is tree control. -- It is a tool that lets you perform queries
on the contents of a CVS archive; you can: get a list of checkins, see
what checkins have been made by a given person, or on a given CVS
branch, or in a particular time period. It also includes tools for
looking at checkin logs (and comments); doing diffs between various
versions of a file; and finding out which person is responsible for
changing a particular line of code ("cvsblame").
* The URL you may wish to start from is
http://www.osafoundation.org/bonsai/ Please note that the LXR links will
not work (we have no LXR installed, and no plans for it at the moment).
If you have any problems with this etc. please send Heikki e-mail heikki
at osafoundation.org .
4. Installer - no major activity this report
5. QA - no major activity this report
6. Ecosystem
* PDA/cell phone project - OSAF needs to understand what the mobile
device will look like and how these devices will be used in 2004 and
beyond in order to make decisions now on how Chandler should
interoperate with these classes of devices and plan to incorporate the
necessary architecture/infrastructure/APIs/etc. at appropriate points in
the Chandler product road map.
http://wiki.osafoundation.org/bin/view/Main/PDAandSyncAnalysis
-----------------------------------------------------------------------
Miscellaneous - 0.2 Release Post Mortem meeting notes:
We didn't want 0.2 to be a big event, since it was a time-based release.
This seems to be what happened. We identified a set of topics relating
to the 0.2 release and spent some time talking about them.
* 1. "Dot Releases" clock-based or features-based? Some believe that we
shouldn't have called it a 0.2 release. Internally we have clock-based
milestone releases leading to the next dot release. Basing milestone
releases on the calendar is good. But basing dot releases on the
calendar is another question. It didn't feel like we hit the sweet spot,
where loose ends were tied up. Also it didn't serve a giant forcing
function for some of the developers, although it did for others.
Certainly it is a forcing function for documentation, but other docs
were blocked because the development wasn't completed.
o We did stop and do some bug-fixing, which is good.
o It seems like letting a dot release slide a week or two is acceptable
to complete a goal. If it's more than that, then there is a planning or
execution failure.
o Proposal:
+ (a) Have some goals for 0.3 -- the pile of stuff we want to have
included. Dot releases should have "units of meaningful accomplishment."
The things that barely miss we'll slip the release a bit. But we won't
slip very much, because this forces us to examine why we missed. Release
0.3 will be clock-ish, but not completely. We might want to revise the
forecast in the middle of the period at least once.
+ (b) Set up a place on the public wiki -- plan, evaluate what we did,
look at the delta between plan and accomplishment, see what we learned.
Let's see if there is a pattern to our errors, like chronic over-optimism.
* 2. Productivity -- how are we doing? Also we had a discussion that 0.2
included only a portion of all the things we had initially hoped to
include. So we need to estimate better, and plan better. We discussed
the need to have a better shared understanding of the interaction
between Chandler building blocks to improve productivity.
* 3. Fit, finish and Quality -- Andy H. Raised the issue of when do we
start focusing on fit, finish and quality? 0.3 will be more of a
completed package than 0.2 was. Brian suggests that once we commit to
fit and finish for something, we should keep it polished going forward.
This idea was well received. As to getting to a release that end users
might use: Chao is working on a plan for what minimal features and
infrastructure would be needed for very hardy types (theoretically, like
those working at OSAF) to start using the release for something,
probably calendar functionality.
* 4. Tracking progress against schedule -- do we have the right system?
How do we improve ability to predict in the 2 or 3 month timeframe?
We'll continue the two week interim milestone releases. Try to figure
out how people estimate their tasks well -- unanswered question: "Can
everyone work the same way?"
* 5. Build issues --"Make" still doesn't work reliably on all platforms.
* 6. Release process -- locking down the tree, and meeting the deadline.
This was smooth this time. Might be more contentious when we have
feature releases.
=======================
OSAF Organization news
=======================
I. Chandler in Higher Education
We are very pleased to announce that at the end of September 2003, the
Andrew W. Mellon Foundation and the 25 university members of the Common
Solutions Group (CSG) agreed to provide OSAF a total of $2.75 million in
grants. These funds will allow OSAF to extend the functionality of the
Chandler software application to meet the information technology needs
of higher education. One result of the funding commitment is that we are
ramping up our hiring plan and have recently posted four new developer
positions.
"Westwood", the Higher Education version of Chandler is expected to ship
a year after, and extend the functionality of Chandler 1.0 to serve the
needs of larger university campuses by implementing nomadic usage and
central repositories, a standards based Calendar Access Protocol (CAP)
client, full interoperability with standards based infrastructures, and
a robust security framework. This work will be based upon the core
functionality and architecture we are creating for Chandler 1.0 rather
than bolted on as an afterthought. To make sure our product will meet
the needs of the higher education community we are forming a Westwood
Advisory Council with representatives of the various constituencies
including research universities, liberal arts colleges, faculty,
administrative staff, and students. This Council will provide advice and
feedback on our development and act as a conduit to the respective
communities. For more information about Westwood visit our website and
Wiki pages devoted to Higher Education.
http://www.osafoundation.org/Chandler_in_higher_ed_TOC_3002_05_13.htm
http://wiki.osafoundation.org/bin/view/Main/ChandlerinHigherEd
II. New Staff at OSAF
Building out the OSAF development staff is a high priority right now. We
have recently posted four new developer positions.
http://www.osafoundation.org/employment.htm
* Software Developer - Applications Infrastructure (posted 10/21/2003)
* Applications Developer (posted 10/21/2003)
* Software Developer - Data Model (posted 10/21/2003)
* Software Developer - Email Backend (posted 10/21/2003)
We are pleased to announce two new staff members who joined us recently,
* Stuart Parmenter our newest Software Engineer. Stuart got involved
with open source at the age of 14. He created the Balsa email client and
has been working on Mozilla for the last 5 years. After spending the
last 4 years at Netscape, his quest for the next big thing has led him
to OSAF, where he will be working on the agent framework.
* Mimi Yin who joins our staff as UI Designer. She will be working hard
to construct an elegant and intuitive visual metaphor for Chandler's
user interface.
III. Visitors
We occasionally meet with representatives from a variety of institutions
with whom we feel it would be important to share information about our
projects. Some of the recent meetings have included:
* Dan Baigent, Colm - Sun GLOW (Calendar project associated with Open
Office) - We exchange information about our respective projects.
IV. OSAF in the News
* OSAF website homepage is now a blog: - The OSAF homepage
http:www.osafoundation.org is now created by a Dreamweaver template that
has a Movable Type blog embedded. Thanks to Morgen, now it's easy to
create an announcement with the blog tool that gets archived/arranged
chronologically and by category, and generates an RSS feed.
* There have been two recent articles on OSAF and Chandler. Recent
Magazine Articles about OSAF
http://www.wired.com/wired/archive/11.11/linus.html?pg=6
o One is a sidebar in the most recent issue of Wired Magazine entitled
"Reinventing Your Inbox: Mitch Kapor brings open source to the masses.",
by Dan Gillmor.
o The other is the top story in the November issue of MIT Technology
Review, "Trash Your Desktop: Mitch Kapor's new, more intuitive computer
interface puts all the information we need to manage our digital lives
at our fingertips, no matter what form it's in.", by Michael Fitzgerald.
You can also see this article as a pdf file with fancier formatting and
photos. http://www.technologyreview.com/articles/fitzgerald1103.asp
* Mitch Kapor recently gave a well attended lecture at the SDForum's
Distinguished Speaker Series at PARC in Palo Alto entitled "Ubiquitous
Open Source: What Does It Mean for the Software Industry?".
(http://www.sdforum.org/p/calEvent.asp?CID=1175&mo=10&yr=2003) The
slides in PowerPoint format are posted on the OSAF website.
http://www.osafoundation.org/presos/SDForum_2_23_2003l.ppt
More information about the Dev
mailing list