[desktop-discuss] Next JDS Desktop release for OpenSolaris

[Glynn Foster]

Hey,

On Mon, 2005-12-19 at 12:24 +0000, karlg wrote:
> We now plan to move the JDS Desktop to a develop to HEAD model. The next release
> will be based on GNOME 2.14. Development will coincide with the GNOME 2.14
> development process.

In case anyone doesn't know what the develop to HEAD model means, it's
basically we're going to stick as close to community upstream
development as possible regardless of what happens in terms of Nevada
integration. In source code management terms, HEAD [or trunk] will
always point to the latest and greatest releases from the upstream
community [1].

I've attached a document that I wrote up a while ago that was the basis
for discussion on what this means across all the different teams. It's a
pretty new and radical approach and it's going to take some time to
figure out - but I personally think it's a lot more exciting from a
community point of view that we'll be tracking what's happening upstream
a lot more [2].


Glynn

[1] There may be some exceptions to this rule. Since most of the current
    desktop components are based on GNOME, it's a pretty predictable 
    6 month release schedule. For other components like Thunderbird and
    Firefox we'll have a little thinking to do

[2] And no, I haven't thought about the consequences of Live Update for
    the Nevada builds - any ideas? :)
-------------- next part --------------
HEAD Development Model

[Wed 27th Jul, 2005]
Introduction

With the JDS team's recent re-organization into OPG, and in particular our focus on 
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 JDS and upstream vanilla GNOME as small as possible.

Current Internal Development

Arguably we have a successful model, having now released 3 separate versions of
JDS. We currently take a released, and relatively stable community snapshot, and
perform productization internally to form JDS. Productization can roughly 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 [as JDS is
current 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.
More harshly, those patches have failed - if they had any value, they would be already 
upstream. 

This could be perceived as a difference in approach from a product
point of view - needing to provide the 'value add' that our 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 Proposal

Simply put, develop to HEAD. Change our development processes so that we do as 
much of the high maintenance work on HEAD, 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. They are 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 to HEAD
     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
  Fix all bugs in HEAD
     If we can continuously monitor the stability of HEAD as above, 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 develop to HEAD
     If we develop all our features to HEAD, then we don't have to worry 
     about trying to get it upstream later. This guarantees us no heavy 
     maintenance on features going forward
  Localize to HEAD
     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
  Document to HEAD
     If we feature develop to HEAD, 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 proposal doesn't intend to map out all the concrete details of how this can work.
Obviously there are quite some hurdles to work out - in terms of maximum benefit for
our time. Quite often, HEAD 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 proposal -

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