[1/2,v2] drm/doc: Allow new UAPI to be used once it's in drm-next/drm-misc-next.
diff mbox series

Message ID 20190424220638.16222-1-eric@anholt.net
State New
Headers show
Series
  • [1/2,v2] drm/doc: Allow new UAPI to be used once it's in drm-next/drm-misc-next.
Related show

Commit Message

Eric Anholt April 24, 2019, 10:06 p.m. UTC
I was trying to figure out if it was permissible to merge the Mesa
side of V3D's CSD support yet while it's in drm-misc-next but not
drm-next, and developers on #dri-devel IRC had differing opinions of
what the requirement was.

v2: Restrict to just drm-next or drm-misc-next on airlied's request.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 Documentation/gpu/drm-uapi.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Daniel Vetter April 25, 2019, 6:33 a.m. UTC | #1
On Wed, Apr 24, 2019 at 03:06:38PM -0700, Eric Anholt wrote:
> I was trying to figure out if it was permissible to merge the Mesa
> side of V3D's CSD support yet while it's in drm-misc-next but not
> drm-next, and developers on #dri-devel IRC had differing opinions of
> what the requirement was.
> 
> v2: Restrict to just drm-next or drm-misc-next on airlied's request.

Personally I think that's a bit too strict (if people want to screw up,
they will be able to anyway). But since I'm all for clearer rules where
possible, this has my support too.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> 
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>  Documentation/gpu/drm-uapi.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index c9fd23efd957..b7a96dc02d21 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -92,9 +92,9 @@ leads to a few additional requirements:
>    requirements by doing a quick fork.
>  
>  - The kernel patch can only be merged after all the above requirements are met,
> -  but it **must** be merged **before** the userspace patches land. uAPI always flows
> -  from the kernel, doing things the other way round risks divergence of the uAPI
> -  definitions and header files.
> +  but it **must** be merged to either drm-next or drm-misc-next **before** the
> +  userspace patches land. uAPI always flows from the kernel, doing things the
> +  other way round risks divergence of the uAPI definitions and header files.
>  
>  These are fairly steep requirements, but have grown out from years of shared
>  pain and experience with uAPI added hastily, and almost always regretted about
> -- 
> 2.20.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Eric Anholt May 16, 2019, 4:38 p.m. UTC | #2
Daniel Vetter <daniel@ffwll.ch> writes:

> On Wed, Apr 24, 2019 at 03:06:38PM -0700, Eric Anholt wrote:
>> I was trying to figure out if it was permissible to merge the Mesa
>> side of V3D's CSD support yet while it's in drm-misc-next but not
>> drm-next, and developers on #dri-devel IRC had differing opinions of
>> what the requirement was.
>> 
>> v2: Restrict to just drm-next or drm-misc-next on airlied's request.
>
> Personally I think that's a bit too strict (if people want to screw up,
> they will be able to anyway). But since I'm all for clearer rules where
> possible, this has my support too.
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Pushed to drm-misc-next now.

Patch
diff mbox series

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index c9fd23efd957..b7a96dc02d21 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -92,9 +92,9 @@  leads to a few additional requirements:
   requirements by doing a quick fork.
 
 - The kernel patch can only be merged after all the above requirements are met,
-  but it **must** be merged **before** the userspace patches land. uAPI always flows
-  from the kernel, doing things the other way round risks divergence of the uAPI
-  definitions and header files.
+  but it **must** be merged to either drm-next or drm-misc-next **before** the
+  userspace patches land. uAPI always flows from the kernel, doing things the
+  other way round risks divergence of the uAPI definitions and header files.
 
 These are fairly steep requirements, but have grown out from years of shared
 pain and experience with uAPI added hastily, and almost always regretted about