[Intel-gfx] drm-intel-next maintenance

[Chris Wilson]

As you may have noticed, Eric has been working hard on the glsl2 compiler
project and rewriting the GL drivers leaving little time for KMS. glsl2 is
a critical project for us and well worth the effort everyone is putting
into it. Thanks all!

So in order to reduce the burden of work on his shoulders, I volunteered
to maintain the upstream trees for i915.ko and take the flak for when
things go pear shaped. Having been discussing the BKM for tree management,
here is what we plan to do.

I have created *3* branches at

http://cgit.freedesktop.org/~ickle/drm-intel.git

and will move them to git.kernel.org as soon as I have an account there.

drm-intel-fixes is the stable branch which contain "regression-only"* fixes
for the current rc kernel. Most of these should be candidates for stable
kernels as well, and should have ideally a bugzilla entry, a tested-by and
a reviewed-by.

* regressions, compilation, hangs and other stability fixes.

drm-intel-staging are proposed patches for -fixes. The primary purpose of
this branch is for communication with bug reporters and testers. By adding
proposed patches to -staging and asking our testers to pull from there we
know precisely what kernel they are using which removes a major source of
confusion when testing. We can then rubber stamp the patches with the
testing history before adding them to -fixes and including them in our
regression testing.

drm-intel-staging will be rewritten frequently as patches evolve. It is
not intended to be a stable base for development or for regression
testing.

drm-intel-next is the unstable development branch. It is where all the
feature work and non-critical fixes will land first. It will be a superset
of -fixes and drm-core-next. Occasionally a patch will be cherry-picked
from -next into -fixes. The mailing list will remain the staging ground
for patch development; it behoves us all to review each other's patches
and to record that review in the patch.

Regression testing will focus on -fixes during the stable period. If a
regression is found and a patch is not immediately forth-coming, we will
revert the offending patch.

Around rc5, about 1 month before the merge window, I will send a pull
request to Dave to merge drm-intel-next into drm-next. This marks the end
of our development cycle and the focus will then be on finding the
regressions in that branch before it is merged into linus/master. So I
will not accept major infrastructure work past that point and we will
begin nightly regression testing on -next -- the belief being that at this
point in the cycle we will have stabilised the -fixes tree to a point where
the number of patches flowing into that branch is close to zero and we can
relax our regression testing on that branch.

If all goes to plan, we should have curbed the number of patches we need
to feed to Linus after -rc1 and so be able to feed our -fixes through
drm-fixes. Only through hard effort can we maintain a stable evolving
driver, so please do give credit and remember those who do the often
overlooked job of testing and reviewing code.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre