Proposal: 1.8 release and development process changes
peter.hutterer at who-t.net
Sat Sep 26 08:08:42 PDT 2009
For 1.8, I would like to propose a new release and development process.
Since I won't be at XDC, I'd appreciate it if this could be brought
up and discussed there.
As you are aware, our current development model and release process
have several issues:
- our release schedule is unpredictable. 1.7 was such an example, we
announce a schedule, then it went silent, then another, revised schedule,
silent again, and then out of nowhere the code freeze and the final
schedule and the actual releases.
- git master is unusable at times.
This hits developers as one suddenly has to spend time fixing other
issues. Worse, it hits testers of new code who are at times unable to fix
the actual issue. This exposes us to limited testing which in turn hurts
- Late testing cycle. Build issues are reported fairly late in the process
when we should be focusing on blocker bugs. Largely caused by the above
We can live with the above, but we shouldn't have to. In particular, it
feels we're making it particularly hard for others to test our code.
Not all is bad, we still manage to get releases out. The number of patches
and reviews on xorg-devel has increased vastly and the number of
contributors seems to increase too. At this rate, it can't take more than a
century and two lab mice to obtain world domination.
Anyway, I propose the following changes to our development and release
1. Feature branches:
Any feature that is potentially disruptive, cannot be merged as a set of
patches in one go, and needs intermediate testing must be developed on a
branch first. When it is deemed ready, it can be merged during the
feature merge window (see below).
Feature branches can work well. For example, the mpx merge last year went
quite smoothly. This process requires discipline though. For example, XI2
was developed on a branch but merged prematurely, resulting in active
development on master. Not how it should be.
2. Three stages: feature merge - bugfix - release freeze
This is possibly the largest impact to our development process.
After a release, the feature merge window opens. Feature branches deemed
ready may be merged into master. During this time, master is expected
unstable and API churn happens.
After the feature merge window, only bugfixes and general fixes may be
merged onto master. Towards the end of this cycle, master should be
stable and all drivers work with master.
After this stage, master freezes for the release process. Patches to go
onto master must hit xorg-devel first and only crucial bugfixes go in
until 1.8 is cut straight from master. Once 1.8.0 is out, the 1.8 branch
is created and the merge window opens again. Note that this is quite
similar to the kernel process but with a central repository.
The argument against an earlier 1.8 branch is that any bugfix on master
should be going into 1.8 anyway so why have a separate branch.
I think 3 + 2 + 1 months should be approporiate for the various stages.
3. Predictable time-based releases
With the above, it should be easier to test master and no half-complete
feature should be blocking master at any point in time.
This allows for monthly snapshots of master so people can test the
Towards the end of the cycle, bi-weekly or weekly snapshots until the RCs
start. Release schedule is announced once and stuck to - within reason of
The above incorporates suggestions from various people I've asked for input
on this. Generally, I've seen a positive attitude towards having more
predictable releases and the use of feature branches.
Note that this process does not address all issues that we currently face
and doesn't intend to. One step at a time.
More information about the xorg-devel