Development Model

Development Model

Glynn Foster, Mon 21st Aug, 2006

Introduction

 With the introduction of OpenSolaris, there is an emphasis on being able to change our development model and processes for the greater gain. Not only that, there's also a priority to keep the delta between OSD and upstream vanilla GNOME as small as possible.

Current Internal Development

 The current development model is relatively simple - take a released, stable community snapshot of the desktop, and then apply a set of productization patches. These patches can be many (averaging 300+ per release) and be divided into the following areas -

• Normal bug fixes - bug fixes with the goal of increasing stability
• Feature patches - patches that, more often than not, are developed to enhance the user experience
• Documentation - provide full and more professional online user help
• Localization - provide full translations for our big 10 languages

 Within those areas we should expect that most of the normal bug fixes, documentation and localization have a higher probability of going upstream, than the feature patches. That has been true to some extents but with a somewhat dated product (OSD in Solaris 10 is currently based on GNOME 2.6) often those patches haven't gone upstream. With every patch that hasn't gone upstream, we have increased the maintainership burden internally. Another way of thinking about it is that those patches have failed - if they had any value, they would be already upstream in some form.

 This could be perceived as a difference in approach from a product point of view - needing to provide the 'value add' that product management want, and consequently making it an easier sell by marketing. Ultimately, this hurts the community that we leverage the code from - we bite the hand that feeds us.

A New Change

 Simply put, develop to the latest unstable community code. Change our development processes so that we do as much of the high maintenance work on this codebase, then productize later. By productize I mean fix only very high priority bugs, and some simple branding.

 So what does that really mean? Well, we need to change our development processes to sync in with the community better. The GNOME community operates on a 6 monthly time based release cycle, which while doesn't certainly make things very easy, it makes it predictable. This isn't just development from a code perspective - it has much wider reaching aims -

• QA - This helps us see the stability of the code that will eventually make it into our productized sources. If we can do as much of that work ahead of time, it'll make things easier later on - not only in terms of schedules.
• Bug fixing - If we can continuously monitor the stability of the unstable branch, then it's easier to fix bugs well ahead of time. Obviously we may have high priority bugs from customers that we will have to fix locally and backport to various releases - this is unavoidable with any development process, but we should aim to minimize it
• Feature development - if we develop all our features to the unstable branch, then we don't have to worry about trying to get it upstream later. This guarantees us no heavy maintenance on features going forward. We need to coordinate our development schedules with the community releases.
• Localization - If we can do the majority of work ahead of time, then like QA, our schedules won't slip. If we're not happy with community translations, work with them rather than against them.
• Documentation - If we feature develop at the right time, and maintain a level of restraint with our branding, then there is no reason that we can't work on documentation within the community.

 This document doesn't intend to map out all the concrete details of how this can work. There are many hurdles to overcome in terms of maximum benefit for our time. Quite often, unstable community code is a rapidly moving target, and we want to avoid wasting effort as much as possible.

Benefits

 There are a couple of benefits to gain from this -

• Less maintenance on our patch set
• Opportunity to steer the community by being active
• Better community trust in Sun
• Less duplication of work
• Potential for more reliable schedules

Stable vs Unstable

 While it would be ideal to only concentrate on unstable community code, we will at some stage need to work on a stable code base. These snapshots of official community stable releases will be the candidates for integration into Solaris. We will not integrate an unstable codebase at any stage, even though the majority of our development time will be on it. Any bugs identified in the stable codebase will be assessed, and depending on the prioritization, will only be fixed in the unstable codebase. Builds will be provided by release engineering for both - unstable and stable branches.