2008 Debate of Build and Release
Here's my write-up from the April Fools memo (http://wiki.laptop.org/go/April_Fool_2008_Build_Process) and Mini-conference presentation. I'll get something on the wiki shortly, probably at http://wiki.laptop.org/go/2008_Debate_of_Build_and_Release. I'd appreciate any comments. Thanks, Charles About The Debate The 2008 Debate on Build and Release started when Charles Merriam (l) wrote an April Fool's document named April Fool 2008 Build Process (l). The document is short and should be read before reading this page. The ideas were then presented as a set of slides (l) at the April 4 Spring Miniconferce (l) Much debate ensued. Build and Release processes and tools change over time as software matures. You can find references to the build and release debates of 2007 (L), which more more concerned with getting any process to work. Debating Debating occurs in several venues: the talk page of this article (l); calls and conferences to be determined; and the devel and testing mailing lists (l). Please start *all* debate posts with Build Debate:. If your posts relate to a section, mention the section. For example, a good subject line might be Build Debate: Time Based Release has another problem. Relevant information, conclusions, and unsolved issues will be eventually be added into this article. If you want to track the progress and conclusions, you may want to watch this page (l) on your watchlist (l). Social vs Technical Problems Thinking about build and release management causes arguments everywhere because it dredges up long standing concerns about corporate strategy and implementation. Build and release management is not a solution to social and business problems, no matter how much you wish it were. Nor will build and release management squeeze seven months of engineering into a six month cycle. Be cognizant of discussions that catapult from release management to general management. Also, recognize that the OLPC project is transitioning rapidly from realizing an impossible dream to managing many thousands of laptops in diverse deployments. People need time to adjust expectations for this change. Social Problems To Address Adopt a Time Based Release System * See Ubuntu's Wiki for an explanation (l) and release schedule [l]. Time Based Release is a practice and procdure to ship based on the calendar instead of based on features completed. The release ships on-time and features still stabilizing will slip forward to ship in the following release. This change in philosophy provides a regular heartbeat of new versions, so that slipped features have a reliable next ship date. The ultimate aim is to always be able to build a nearly shipping version, This means an exceptional circumstance requiring a special release would only need Disaster Insurance final quality testing. New features still gaining quality are developed in separate branches until they can be incorporated into a solid branch. This is a contentious discussion and took up most of the MiniConference discussion time: * Every project starts with feature based releases until it hits a minimum functionality. Stability and predictability become issues after there are users relying on the project's functionality. OLPC now has many schoolchildren, teachers, and developers relying on releases. * Delaying releases to serve one market breaks other markets: many bug fixes and improvements will have been tested and ready each release date. Some countries will only pick up one release per year and may not be able to adopt any changes if release dates slip. * Time-based releases also trigger contemplation of the changing management directives for each release. Having specific release dates may make the discussion easier. Specifically, an inflexible ship-date grounds discussions in reality and helps to evaluate trade-offs of important features. The build manager creates a release on a date from whatever engineering is completed. Build Manager Not Necessarily On Site in Cambridge This idea brings more contentious debate and contemplation. The role of the build manager is to make sure releases happen on specific dates and to balance adherence to a release process with the flexibility of exceptions to that process. He or she does not get features by going down the hall to beat up engineers for patches. Also, a growing percentage of development happens in the open source community, which is off-site. Buy-in From OLPC Foundation Before Work Buy-in facilitates work that is used. Work proceeds with only partial commitment: full adoption will take a year of successes to cement. Participants at the Mini Conference believed the minimum buy-in for work to commence was doable. OLPC Foundation must agree to rename Update-1 to something with a year designation. The exact name is flexible, e.g., 2008 Release 1 and XO-08, April Edition are both fine. This commits to releases annually, closer
Re: 2008 Debate of Build and Release
one thing to be very careful of with a date-based schedule is that as you near the release data you need to be extremely intolorent of regressions. it's useually better to delay a feature becouse you have to revert a patch to fix a regression then it is to break someone's existing setup becouse someone else thought a different feature was more important. as long as the steps are forward, people will accept small steps, and many steps, but if they feel that they are playing russian roulete with each upgrade there will be problems. David Lang On Sat, 5 Apr 2008, Charles Merriam wrote: Here's my write-up from the April Fools memo (http://wiki.laptop.org/go/April_Fool_2008_Build_Process) and Mini-conference presentation. I'll get something on the wiki shortly, probably at http://wiki.laptop.org/go/2008_Debate_of_Build_and_Release. I'd appreciate any comments. Thanks, Charles About The Debate The 2008 Debate on Build and Release started when Charles Merriam (l) wrote an April Fool's document named April Fool 2008 Build Process (l). The document is short and should be read before reading this page. The ideas were then presented as a set of slides (l) at the April 4 Spring Miniconferce (l) Much debate ensued. Build and Release processes and tools change over time as software matures. You can find references to the build and release debates of 2007 (L), which more more concerned with getting any process to work. Debating Debating occurs in several venues: the talk page of this article (l); calls and conferences to be determined; and the devel and testing mailing lists (l). Please start *all* debate posts with Build Debate:. If your posts relate to a section, mention the section. For example, a good subject line might be Build Debate: Time Based Release has another problem. Relevant information, conclusions, and unsolved issues will be eventually be added into this article. If you want to track the progress and conclusions, you may want to watch this page (l) on your watchlist (l). Social vs Technical Problems Thinking about build and release management causes arguments everywhere because it dredges up long standing concerns about corporate strategy and implementation. Build and release management is not a solution to social and business problems, no matter how much you wish it were. Nor will build and release management squeeze seven months of engineering into a six month cycle. Be cognizant of discussions that catapult from release management to general management. Also, recognize that the OLPC project is transitioning rapidly from realizing an impossible dream to managing many thousands of laptops in diverse deployments. People need time to adjust expectations for this change. Social Problems To Address Adopt a Time Based Release System * See Ubuntu's Wiki for an explanation (l) and release schedule [l]. Time Based Release is a practice and procdure to ship based on the calendar instead of based on features completed. The release ships on-time and features still stabilizing will slip forward to ship in the following release. This change in philosophy provides a regular heartbeat of new versions, so that slipped features have a reliable next ship date. The ultimate aim is to always be able to build a nearly shipping version, This means an exceptional circumstance requiring a special release would only need Disaster Insurance final quality testing. New features still gaining quality are developed in separate branches until they can be incorporated into a solid branch. This is a contentious discussion and took up most of the MiniConference discussion time: * Every project starts with feature based releases until it hits a minimum functionality. Stability and predictability become issues after there are users relying on the project's functionality. OLPC now has many schoolchildren, teachers, and developers relying on releases. * Delaying releases to serve one market breaks other markets: many bug fixes and improvements will have been tested and ready each release date. Some countries will only pick up one release per year and may not be able to adopt any changes if release dates slip. * Time-based releases also trigger contemplation of the changing management directives for each release. Having specific release dates may make the discussion easier. Specifically, an inflexible ship-date grounds discussions in reality and helps to evaluate trade-offs of important features. The build manager creates a release on a date from whatever engineering is completed. Build Manager Not Necessarily On Site in Cambridge This idea brings more contentious debate and contemplation. The role of the build manager is to make sure releases happen on specific dates and to balance adherence to a release process with the flexibility of exceptions to that process. He or she does not get
