Commit eadf71cd authored by Daniel Vetter's avatar Daniel Vetter

drm/doc: Document feature merge deadlines

The discussion pretty much concluded without objections, let's
document what we agreed on.

Cc'ing linux-doc for the new tag in Documentation/process/index.rst.
Acked-by: default avatarDave Airlie <airlied@gmail.com>
Reviewed-by: default avatarSean Paul <seanpaul@chromium.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: Dave Airlie <airlied@gmail.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Lukas Wunner <lukas@wunner.de>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170321155228.30287-1-daniel.vetter@ffwll.ch
parent 6a0f9ebf
...@@ -60,3 +60,28 @@ checkpatch or sparse. We welcome such contributions. ...@@ -60,3 +60,28 @@ checkpatch or sparse. We welcome such contributions.
Anyone looking to kick it up a notch can find a list of janitorial tasks on Anyone looking to kick it up a notch can find a list of janitorial tasks on
the :ref:`TODO list <todo>`. the :ref:`TODO list <todo>`.
Contribution Process
====================
Mostly the DRM subsystem works like any other kernel subsystem, see :ref:`the
main process guidelines and documentation <process_index>` for how things work.
Here we just document some of the specialities of the GPU subsystem.
Feature Merge Deadlines
-----------------------
All feature work must be in the linux-next tree by the -rc6 release of the
current release cycle, otherwise they must be postponed and can't reach the next
merge window. All patches must have landed in the drm-next tree by latest -rc7,
but if your branch is not in linux-next then this must have happened by -rc6
already.
After that point only bugfixes (like after the upstream merge window has closed
with the -rc1 release) are allowed. No new platform enabling or new drivers are
allowed.
This means that there's a blackout-period of about one month where feature work
can't be merged. The recommended way to deal with that is having a -next tree
that's always open, but making sure to not feed it into linux-next during the
blackout period. As an example, drm-misc works like that.
...@@ -3,6 +3,7 @@ ...@@ -3,6 +3,7 @@
\renewcommand\thesection* \renewcommand\thesection*
\renewcommand\thesubsection* \renewcommand\thesubsection*
.. _process_index:
Working with the kernel development community Working with the kernel development community
============================================= =============================================
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment