Release Process (Dennis' Take)
dennis at ausil.us
Fri May 23 23:48:40 EDT 2008
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the Devel