Proposal: 1.8 release and development process changes

[Peter Hutterer]

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
  everyone.
- 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
  problem.

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
process:

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
   tarballs early.
   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
   course.

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.

Comments appreciated.

Cheers,
  Peter