New release process for 1.8 (READ THIS)

[Dave Airlie]

On Wed, 2009-09-30 at 18:35 -0700, Daniel Stone wrote:
> Hi all,
> Following on from Peter's email about the 1.8/7.6 release process[0], we
> had a BoF about the same[1] at XDC.  Everyone broadly agreed on the
> substance of Peter's mail, and here are our rough conclusions.
> 
> Release process: We're going to aim for a six-month release process, as
> Peter outlined, with 3 months feature freeze, 2 months bugfix, and the
> final month release freeze.  We're going to start this for 1.8, and
> hopefully we'll be able to land predictable releases.
> 
> 7.6: Either Peter or keithp will be the RM: they can arm-wrestle for it.
> I assume the six-month cycle will start on the day 1.7/7.5 is released
> (hopefully Monday).
> 
> Development model: xserver master will be closed to general commits; it
> will be owned by the RM, or one of their delegates.  Again, DO NOT
> COMMIT DIRECTLY TO XSERVER MASTER.  Everyone should have their own
> xserver trees, and/or one per subsystem (I'll have xserver-xkb and an
> input tree, I guess Peter will have an input tree, there should be an
> EXA tree, etc, etc).  When you want to push something to master, either
> send patches to the list, or send a pull request for your tree.  ajax
> has quite unwisely volunteered to run a trivial-patch tree, accumulating
> random misc.  When you send a pull request or patches, it's expected
> that they've been tested and are working to preserve bisectability, and
> don't destroy ABI every other commit, so feel free to buffer them up a
> bit.  Judicious use of rebase -i is not wholly discouraged.  I know this
> sounds concerning, but if your merge request just gets forgotten or
> dropped on the floor, bug us until we make it happen.

My main issue with this is, while we'd like to be the kernel, we have in
no way got the developer/testers bandwidth they have. Generally when
developing a feature for the kernel, you can find someone else to
interact with while you write the code and bounce it around to get the
bugs out, etc.

With X generally requests for testing things no on master and not
directly affecting another developer at that point go unnoticed, the
only way stuff really gets tested in X is indirectly, by people cloning
master and running it, its unfortunate but I don't think its due to our
process but lack of bandwidth.

So I feel locking down master is going to get messy fast, I agree
all major developments should be done on branches, but we have many
incremental improvements in areas like EXA where we have no fulltime
developers working on it and the only real way for it to get tested
across drivers is to shove it into master. Also having things in master
means you get indirect cross testing, so if I want to add something new
I end up having to test all the new stuff other people have merged.

The other thing is we need to stop being afraid of git revert I think
judicious use of revert could resolve a lot of our problems (read:
_X_EXPORT). We also get to keep history of why we hated something.

> Future: Around 1.10, we'd like to merge the drivers back into the core
> so we can start getting a coherent API (well, any API would be a start).
> We're also working on a much better testing model, with functional
> testing as well as XTS, so we can exercise modesetting, input
> functionality, real-world rendering, etc.

\o/, I got the shit shot out of me for suggesting that last year,
wonders whats changed.


Dave.