Release Process (Dennis' Take)

[Dennis Gilmore]

I have a few ideas on how we should do this.  It is largely influenced by 
Fedora  and as we are based on fedora and we *SHOULD* be working with fedora  
i think that should weigh heavily in in its favour.

Major disruptive development and change happens in a development branch.  when 
it gets closer to basing a release on the development branch things slow down 
and stabalise.  This branch will sometimes not work  but that's ok.  this is 
where we can define major goals and do the most disruptive work.  i would 
like to see us have images based on fedora's rawhide.  with a weekly image 
and  using yum in the interim to pull in updates  we can do alot of new and 
boundry pushing work.


the development tree will get forked off at set times for new stable releases.   
at this point the new branch will be used for final stabalisation while the 
devel branch moves forward.  once the branch is stable we will re-target 
builds to an updates testing build target.  updates-testing will be tested 
via yum updates.  when deemed stable they will move into updates.  we can 
build images from stable and updates.  this will allow us to do bug fix 
builds as point releases.  By using yum we can easily test pending updates. 

We can then maintain multiple stable trees. For instance OLPC-2 OLPC-3 
OLPC-3.1 OLPC-3.2 OLPC-4 OLPC-4.1 

To date we have had one major flaw.  we have done development and stable 
releases form the same tree.  this causes us issues.  Due to the way 
inheritance works in koji we can do many stable releases based on the same 
fedora release.  The one thing we need to ensure we do is to create a new cvs 
branch when we do a new stable release.  bug fix releases do not need new 
branches as they come from updates-testing.

I would like us to define a set of features for a release  but for it to be 
time based,  this gives us goals to work towards.  We need to regularly 
evaluate features and see if we drop them or put more resources on them to 
ensure that they are completed in time.  We need to be very clear in what we 
aim to achieve and do everything we can to make sure it happens.  these 
features/goals,  should be for infrastructure, support, and all the other 
pieces that make up OLPC.  

Lastly we should have fun while we do this.  


Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080523/3e34ec8f/attachment.sig>