Plan of Record-2008/Draft 3

This is the release management half of Draft 3. I have some thoughts on development strategy which I'll post as I'm able. For older documents, please see Plan_of_Record-2008/Draft_2 and my August planning notes

Acknowledgments: Mitch Bradley simplified this essay's prose.

--Michael Stone 23:48, 13 May 2008 (EDT)

RM: Overview and Goals

This document is part of an overall statement of the "who, what, where, when, why, and how" of the development of the OLPC software platform as viewed from April, 2008. It is being written to ameliorate concerns that OLPC's software development effort lacks focus, direction, and predictability.

Its scope is the next eight months of development and particularly the next four months. Its audiences are the OLPC Functional Directors who will approve or amend it, the community of people who will carry it out (both OLPC employees and members at large), the people who use software produced by the OLPC technical community, and the general public.

This document must:

• represent the diversity of views within the technical community about the risks and opportunities afforded by the recognized paths forward,
• state and justify one primary path that we intend to take, and
• explain our fallback plan in case of roadblocks.

In its final form, it will also explain what feedback we have received from sales & deployment. In its draft form, it will propose a reasonable deadline for revisions based on new feedback from those teams. I suggest the week of May 22, 2008.

RM: Notes and Caveats

This document is a capsule summary of my thoughts on release processes. It is not about our current work priorities, which are discussed at Priorities-2008.

Also, labor is critical to our ability to carry out plans. We accept labor from individual community members, partners, and employees. A table of available labor can be found at Available Labor-2008

Lastly, some context: this document arose from an ongoing argument about interleaving periods of development and release versus doing both simultaneously. In parallel, we've argued about when we should release and what what we should include.

First, arguments, then my proposal.

RM: Release Costs

Release planning must consider development, release, and support costs. To date, we have made "omnibus" releases rather than incremental releases. They impose different costs.

We have made several "omnibus" releases with some success. They "free" us to concentrate solely on software development by deferring integration. However, these releases take unpredictable amounts of time to stabilize because they are hard to debug. They increase the risk posed by mid-stream priority changes because we go for long periods of time with no new stable version. Finally, it is harder to write release notes describing simultaneous change than describing incremental change.

Support costs: comprehensive releases are especially expensive because deployments have large investments in training, infrastructure, and ancillary resources like manuals. These factors make deployments hungry for "more polished" builds which capitalize on their sunk costs and perhaps for "tech previews" which they can use for longer-term planning. However, unfinished features are equally expensive to deploy and may require comprehensive releases.

RM: Release Mechanisms

We should:

1. Appoint a release manager to govern a single release stream to smoothly accumulate releasable material.
   • - That's me.
2. Define a tentative date for closing the release stream and execute the release checklist.
   • - Presently, we expect to make a bug-fix release in 3-4 weeks and a bigger bug-fix release in August.
3. Oversee the release manager via regular public feedback on current progress, immediate needs, and risks.
   • - The release manager is the authority on what is shipping and what is slipping. Public writing allows more comprehensive oversight than does twiddling bug priorities in Trac.
4. Enter work into the release queue by negotiating a "contract" with the release manager describing:
   1. the required quality,
   2. a test plan for judging the work,
   3. who will execute the test plan, and
   4. the consequences of breaking the contract.
   • - Successful continuous execution of these contracts will provide a metric for judging the performance of the technical team and the release manager.
   • - When necessary and with public buy-in, release managers may vary their means of governance, e.g. between serializing changes and harvest-then-sort.

If accepted, this description should be expanded into the scheduled software release process.

RM: Conclusion

The release process and considerations I have described above will allow us to make both bug-fix and scheduled releases in confidence that we will deliver increasingly good software to our clients.

However, each release impacts our ability to make future releases in many ways. For example, it becomes harder to maintain and disseminate knowledge of the relationship between bugs, work items, and releases. Consequently, important criteria for this essay are:

Does it help scale our project?

Does it encourage our users to accept responsibility for creating the software they need and for teaching others what they have learned?

I believe that it does and that it will. Consequently, I say: we've got a lot of software to write, so please help kick this plan into shape, get it ratified, and make some releases we can be proud of.