From eadf71cd8c6d837828b4e95e9130f666ab7b4c61 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Tue, 21 Mar 2017 16:52:28 +0100 Subject: 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: Dave Airlie Reviewed-by: Sean Paul Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Cc: Dave Airlie Cc: Sean Paul Cc: Jani Nikula Cc: Alex Deucher Cc: Lukas Wunner Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170321155228.30287-1-daniel.vetter@ffwll.ch --- Documentation/gpu/introduction.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'Documentation/gpu') diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 1f8bd5ef5f9d..05a82bdfbca4 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -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 the :ref:`TODO list `. + +Contribution Process +==================== + +Mostly the DRM subsystem works like any other kernel subsystem, see :ref:`the +main process guidelines and documentation ` 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. -- cgit