The Xaraya 1.0 Manifesto

• The first major-revision-number milestone release (Xaraya 1.0) of the Xaraya application framework. A release of higher quality than any delivered so far, on whose quality our reputation is at stake precisely because 1.0 is such a coveted and feared version number.
• A set of promises to keep compatibility with various APIs, both from core and module scope, until a 2.0 or higher-numbered major release. All milestone releases and repo development between 1.0 and 2.0 will preserve frozen interface compatibility. Xaraya 1.0 is a greenlight to hackers, corporations, and book authors to get busy building atop this stable base set of APIs.
• A stable, long-lived scenario off of the Xaraya.com bitkeeper core tree (Xaraya 1.0 scenario). Interested parties should collaborate, with support from the Xaraya developers, in developing conservative fixes for critical bugs in this scenario. Anyone who wants a baseline for development that will work with the public APIs of Xaraya 1.0 is free to develop against this 1.0 scenario.

why

Xaraya consumers, including many companies developing products, need a stable, long-lived scenario with these properties:

• API compatibility commitments.
• Consistent Module (version) identification (so at least anyone can know which versions are supported in the 1.0 core release).
• Enough modularity that important core parts (e.g., BlockLayout) could stand alone.
• Stability -- acceptable MTBF, no serious dataloss bugs.
• Good performance and memory footprint.
• Better-than-any-competition standards compliance.
• Usability, correctness, polish 

This need is acute: if Xaraya.com does not create such a scenario to share with individual companies and organizations, various consumers of the code will do it themselves, with less information sharing, coordinated effort, and consequent quality than we would like.

We think the world will be a better place, with more hands helping to improve Xaraya, and more people benefiting from distributions of Xaraya, if Xaraya.com hosts a consolidated, stable, and long-lived scenario, along with the active, ongoing development of that scenario. This scenario obviously entails overhead in driving, merging, reviewing, and testing. We're not sure exactly how it will be managed (what its roadmap will be), yet -- but we see the need, we want to have a plan, and we welcome your input.

A note on the 1.0 scenario: It's conceivable that non-conservative changes could take place on the 1.0 scenario, as long as they are "additive". But we would much prefer that the bulk of the active developers keep hacking on the repo, and take advantage of compatibility of frozen interfaces to deliver modules built from repo sources that work with any 1.x milestone.

how

This stable, long-lived, branded scenario cannot happen without concerted effort to fix certain bugs. We need to identify the bugs and drive the buglist to near-zero. To do that, without being utterly date-driven, we need to pick a small number of milestones during which we ask developers to schedule fixes for their Xaraya1.0 bugs. Of course, contributors have different ideas about what constitutes a Xaraya1.0 bug. Some people believe that most standards-compliance bugs should be fixed for anything that deserves the 1.0 brand. That's ok, but the number of milestones needed to fix such a long list is hard to guess, but probably quite large at the current fix rate.

This is a call to all Xaraya developers: if you believe, as we do, that the world needs a "1.0" from Xaraya.com soon, then please concentrate your efforts on the dependencies of bug 77, the Xaraya1.0 tracking bug.

Given the constraints identified above, we still have a short-term requirement for a stable, relatively long-lived (a year minimum, at a guess) scenario. However we brand this release and scenario, we need to develop a schedule that converges on a stable, useful release in at most five milestones, preferably fewer (but likely no fewer than three). So we are asking people to schedule their most important Xaraya1.0 bugfixes over the four milestones starting with 0.9.6, through 0.9.9.

As we've said often, we're not looking for new features; we want stability, performance, best-available standards compliance, tolerably few bugs, and good APIs.

Features cost us time directly (opportunity costs born by those implementing the features, who likely could instead help fix 1.0 bugs) and indirectly (collateral costs on code reviewers, documentation writers, and other helpers). If you think you must have a feature by 1.0, please be prepared to say why to the PMC, and be prepared to hear "we can't support work on that feature until after 1.0 has branched" in reply.

If, as seems likely, commercial contributors must have features implemented in the milestones before 1.0 scenarioes, we may wish to isolate those features to BK scenatios. The excellent BitKeeper tool makes this relatively easy, so there is no need for third parties to wait if there is a "must have" we cannot support before 1.0. We may trade features for fixes to let in a very few exceptions that have been proven to be innocuous. But we won't get a short-term "1.0" done if we don't take a hard line, and we ask all our contributors to join us in holding that line.

when

The majority of developers we spoke to believes that the "1.0" brand should be used sooner rather than later to identify our stable, long-lived scenario with API commitments. We believe "sooner" means within the next two months, based on feedback from developers, current beta users and some commercial customers in need of such a scenario.

We contend that a milestone where only fixes for blocker bugs and other severe bugs (e.g., dataloss) get checked in, with lots of regression testing and code review, is necessary before we can confidently brand a Xaraya1.0. The 1.0 milestone period is therefore likely to be one during which the tree is closed to all but PMC-approved changes.

All of this taken together suggests that we have at most 0.9.6 through 0.9.9 to get to a Xaraya1.0 milestone during which the stable repo is closed to all but a relative few bug fixes, and everyone is focused on testing. There's obviously a lot of work to do to get to that milestone, and more to be said about how to organize the work, but I'll leave that for a followup to this document (Xaraya 1.0 roadmap planning, which will be published within a couple of days). Your feedback is welcome.

If things go well, we'll be within a milestone of 1.0 after 0.9.9. If 1.0 seems to continually recede as we approach it, our definition of 1.0 in terms of bugs to be fixed is broken. Therefore we will continually review the schedule and the outstanding bugs. If it takes an extra milestone (0.9.10), but 1.0 is reached soon enough, so beit -- but no one should count on an extra milestone. There won't be two or more extra milestones, or again, we will have failed toconverge on a short-term stability scenario and release within two months.

who

We need help from all of you who have bugs linked to the Xaraya 1.0 tracking bug. (But please, don't spam the bug, change its dependencies, or otherwise put your bugzilla access at risk! Use the newsgroups for discussion.) That buglist might not be complete. It will be constantly monitored and updated in consultation with key people in the various areas, and with your feedback. The dependency list has stabilized in the last weeks though and we're pretty confident we have the required dependencies set. Final say for what goes into 1.0 must come down to PMC -- but there are layers of people to whom we delegate, and whose judgement and consensus we trust, in order to do the right thing. We are now identifying owners for the dependencies of bug 77. If you want to help by owning one of these tracking bugs, please mail us.

If you believe a bug should be fixed by 1.0, nominate it by setting the Xaraya1.0 keyword. The bug may be assigned and targeted at 1.0 or a nearer milestone. If PMC believes the bug is important to 1.0, it will be linked as a dependency. Feel free to propose the bug if it is not linked, targeted, or even assigned yet, but please ask yourself:

• Is fixing this bug vital to web content developers, Xaraya distributors, or others who will depend on 1.0 for stable code and a minimal set of frozen APIs?
• Is there no alternative to fixing the bug that frees people to work on other 1.0 bugs?
• What goes wrong if we don't fix the bug, and just live with it for 1.0?
• What do we give up from 1.0 in exchange for fixing the bug?
• Can you stare down slashdot and C|net together and at the same time, argue credibly that the bug is a 1.0 stop-ship problem? While we are not yet at the "about to ship, why should we take any more risk" stage, this question can help us prioritize and avoid unpleasant surprises later, when 1.0 is within our grasp

To be able to decide with some level of objectivity what is needed for Xaraya 1.0 the PMC uses a points system. Within the focus areas below we loosely define points for each item and order the tasks from high to low with the assigned points. This gives us a rough order of execution.

Xaraya 1.0 focus areas:

• User interface
  • 1 point : Does it improve useability in a necessary way?
  • 1 point : Is it badly needed for visual attractiveness?
• Performance
  • 2 points : Is it an assigned bug and dependent on bug #77?
  • 1 point : Would the caching operation break if the task is not performed
  • 1 point : Gain performance in 90% of situations with more than 5%?
• Functionality
  • 1 point : Is the module on inclusion list for base distibution of 1.0
  • 1 point : Task easily isolated and are side-effects very well known?
  • 2 points : PMC discretion ;-)
  • 1 point : Anything obviously and badly broken that doesn't fall into another category.
• Standards
  • 1 point : Is it needed for xhtml compliance?
• Stability
  • 2 points : if not fixed it crashes the site or dataloss occurs
• Footprint
  • 2 points : Remove deadwood, redundancies and duplication (e.g. tree uses)
  • 2 points : Reduce core loading requirements
• Security and Privacy
  • 2 points : it fixes a security hole
• Party
  • 1 point : anything which gets us closer to this

The threshold lies round and about 6-8 points. If a task scores below that it is very likely it will not be supported in the 1.0 scenario. Developers are encouraged to use the above mechanism to decide in which scenario, if at all, the task should be performed.

We strongly believe in the above to make Xaraya 1.0 a fact. We have come a long way in the last 18 months or so and great innovative designs have made it to actual implementation. The daunting task we face now is to finish our first job and produce an excellent one-dot-oh release as a great beginning to the rest of the lifecycle of Xaraya.

Marcel van der Boom

Xaraya PMC

Footnotes: * This document is based on the mozilla 1.0 manifesto by Brendan Eich