Hi all,
Because Keith is routinely really busy with all kinds of things, notably gathering fixes for drm-intel-fixes, the patch merge process for the next release cycle sometimes falls behind. To support him and improve things I've been volunteered to take over handling the -next tree.
The main aim is to shift the drm/i915 -next merge process massively ahead with the goals to: - Reduce pressure to merge questionable patches into -rc kernels because the -next tree is not yet open for patches. - Allow our QA at Intel and also the community to actually test things before they land in mainline. The lack of such testing has severly bitten us in the past few releases. - Refocus -fixes on handling regressions with absolute top priority (as it should). - And generally get a steady and predictable patch-flow towards mainline back into gears.
I plan to run this -next tree with a few simple rules: - I'll open the drm/i915 -next tree around -rc1 (maybe earlier in the future) and cut regular new trees about every 2nd week or so. 2 weeks should be enough for both our qa and the community to give it some decent testing.
- I intend to send out the previous -next to Dave Airlie (assuming it tests ok) so that he has a good check on the stuff that's going on in i915-land. A few other people also asked for a better overview of what's going on on drm/i915 - I'll plan to announce every new -next tree with a short mail (maybe together with the pull request to Dave for the old one).
- -next will close about 1-2 weeks before the merge opens. No new features after that point for a given release cycle.
- To make this really work we also need to cut down on what can go into -fixes. drm/i915 unfortunately has the reputation that deserves it a bunch of draconian rules (which are stricter than drm/* in general):
- Only fixes for serious issues and regressions after the -next tree went to Dave. - After -rc2 regression fixes only. It simply happend why too often that an "obvious" patch blew up late in the -rc release cycle, my patches included. - After -rc4/5 only reverts and disable patches. Imo it's way too late to play games by then, the real fix should go straight to -next (which will close only a few weeks afterwards already).
- Regressions have top priority, if they get neglected due to ongoing work headed for -next I'll refuse to merge the patches.
- We have a test-suite in the intel-gpu-tools package for the kernel. Expect me to be annoying about patches that should have testcases for them but don't. This includes new features, but also bugs that can be reproduced with a reasonable amount of effort.
- To avoid me pushing utter crack I will only merge my own patches after they have gathered sufficient review on intel-gfx. Please yell at me at the top of your voice (and in public) if I violate this.
- The main discussion list for patches to drm/i915 is intel-gfx@lists.freedesktop.org - I don't keep up with lkml usually.
- I'll reserve my human right to act like an incompetent arrogant fool once in a while.
Last but not least, the new tree is available at
http://cgit.freedesktop.org/~danvet/drm-intel git://people.freedesktop.org/~danvet/drm-intel
drm-intel-next is the main branch, but I expect at least a for-airlied branch for pull requests and maybe other branches with proposed patches to show up.
Comments, flames and suggestions highly welcome.
Yours, Daniel
PS: Quick version for people with too short attentation spans:
- -next will open around -rc1, a new tree should show up about every second week. -next trees that are tested will regurarly be forwarded to Dave.
- No stuff in -fixes that should go into -next instead.
- -next will close for features about 1-2 weeks ahead of the upstream merge window.
- Regressions have top priority.
- Implementing proper tests is required.
- Hit me hard if I break these rules for my own patches.
- Sometimes I'll screw things up badly.
Now grab the tree from
git://people.freedesktop.org/~danvet/drm-intel