Introduction for Developers

Developers What to Expect

Chandler 0.1 is available. Our CVS repository is open for anonymous downloads of our source. The bug tracking system is available for general use. OSAF has published a set of documents about our vision, the Chandler architecture and roadmap.

But what does this actually mean for the Chandler community? What should you expect from us, what are we prepared to respond to, and how can we best work together to move Chandler forward as quickly as possible. What should we expect from those interested in Chandler, and what do potential contributors need to remain excited and involved? OSAF staff doesn't have all the answers of course, I'm not sure we even know all the right questions yet ;-) But we have done some thinking about this, we do have some idea what we'll be focusing on now, and where we know we need help. I'll describe this and we can start the discussion.

The Release Itself: Timing and Rationale

As the name implies, Chandler 0.1 is obviously skeletal in functionality and only a partial implementation of our architecture. We decided to release the code at this early stage for a number of reasons:

• We want to demonstrate how real we are. Some may think we're well along for an 0.1 release; others may fell we haven't gotten very far yet. But whatever the individual opinion, there is now code and documentation -- actual data -- to evaluate. And there will be more.
• We want our development systems (CVS, bugzilla, etc) open and used by the community. And to do this, we wanted a core set of working code and related documents to be available. We felt that having people review code before any of it worked together and before there was much documentation describing the architecture, vision, or product planning would not be a good use of time. We've got that core set of code now. It's rudimentary, but it builds, runs, and demonstrates some of the flavor of what we hope Chandler will become. Since it's better to develop open work habits earlier rather than later, we created a release as soon as we had that core of working code.
• We hope people will join us. We've had great assistance through the mailing lists. But full involvement can't happen until there is code in an open development process.

Getting Involved with Development

There are several areas where we know help would be invaluable. You may think of others; let us know when you do. For now, here's our starting point.

1. Testing, Filing Bug Reports and Fixing Bugs

If you find problems of the sort listed below, please look to see if a bug exists. If there is no bug, then help us out by filing a bug.

• Corruption or loss of data
• Moving between parcels doesn't work
• Problems in the parcel application framework which make it difficult to write parcels
• Inappropriate use of python, wxwindows

Please do so carefully. A well-written bug report is worth immensely more than a mediocre bug report. Take a look at the bug-filing guidelines and give it your best shot.

If you've got a proposed fix for the bug, so much the better. If your fix is very short you can include in as a comment in the relevant bug report. If the fix is more elaborate, then Bugzilla has a "Create a New Attachment" feature which you can use to attach your proposed fix to the bug.

Please don’t file bugs for:

• UI imperfections. We haven't even started to focus on this.
• Unimplemented functionality. We don't view each piece of unimplemented functionality as a bug, as least not yet. If you have ideas about what the product ought to do eventually, please turn to the mailing lists and wiki for information and discussion. We expect that discussions of functionality will occur in the mailing lists (as they have been), perhaps move to the wiki, and end up as bugs only after there's a reasonably clear understanding of the nature and priority of the functionality.

In the future we should have a written set of pre-determined actions (e.g., create a calendar event, resize it, moved it, delete it) to follow in testing Chandler. If anyone wants to write this document, please jump in. An example of such a set can be found in the Mozilla project at: http://www.mozilla.org/quality/smoketests/. The Mozilla tests (known as "smoketests") are far more complex than would make sense for Chandler currently, but they give an idea of the kind of listing that would be very helpful.

2. Writing Additional Viewer Parcels

Please, if you're interested, give this a try. We expect that there are lots of tremendous ideas for viewer parcels that we will never think of, and wouldn't implement as well as you anyway. There is a set of instructions for how to write a parcel at: http://chandlerproject.org/Main/HowToWriteAParcelTutorial. If you've got a parcel you'd like the world to know about, include it on our index at: http://chandlerproject.org/Main/ThirdPartyParcels.

3. Code Review

If you have expertise with Python, or wxWindows which would improve our code, we'd love to hear it. General comments should probably go to the "dev" mailing list. A specific comment about a specific piece of code might make more sense as a bug.

4. Database, security and email experts

We're looking for key participants in the database, security and email areas; we even have employment opportunities in the security and email realms. So if you know someone with great expertise in one of these areas and the ability to apply that expertise to the Chandler world, please send them our way.

Future Releases

We don't have a crisp idea of how long the 0.2 development cycle will take. That's because we'll be looking into key architectural issues for 0.2, and developing an acceptable initial implementation won't be quick. And of course, we want to get the initial implementation thought out before we go too far down the path of end user features.

During the 0.2 development cycle the CVS repository will remain open (naturally) and developers can check the state of the code at any time. We'll probably start creating daily builds sometime in the 0.2 cycle, although they may be broken for ongoing periods as the architectural features coalesce. We're not yet sure how often we'll do snapshots, where we stop, check the status of the tree, and decide what if anything needs to be fixed before we go on. We'll keep you posted as we figure this out.

IRC Chats

OSAF operates a public Internet Relay Chat channel for online discussions about Chandler development. OSAF developers are often available online through this mechanism. We also hold periodic scheduled sessions with a featured guest and a specific topic. Our wiki has more information about our IRC channel, and a listing of scheduled and planned-but-not-yet-scheduled sessions and topics. You can also view a log of past IRC sessions.