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

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

Commit Message

Eric Anholt April 24, 2019, 6:56 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.  Propose a clarification here to see if Dave
Airlie agrees.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

Personally, I thought the rule was "has to be in drm-next", but
assuming our review processes aren't totally broken, this should be
enough.

 Documentation/gpu/drm-uapi.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Comments

Daniel Vetter April 24, 2019, 7:35 p.m. UTC | #1
On Wed, Apr 24, 2019 at 11:56:16AM -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.  Propose a clarification here to see if Dave
> Airlie agrees.
> 
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> 
> Personally, I thought the rule was "has to be in drm-next", but
> assuming our review processes aren't totally broken, this should be
> enough.

Yeah if you end up with a revert on your hands the process failed much
harder and you get to keep the pieces no matter what. Not sure we should
clarify whether you need a stable sha1 or not (helps with cross
referencing uapi header updates), but imo good as is. And matches what
I've been doing/recommending past few years.

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

> 
>  Documentation/gpu/drm-uapi.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index c9fd23efd957..8e5545dfbf82 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -92,8 +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
> +  but it **must** be merged to the driver's -next tree (as documented in
> +  MAINTAINERS) **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
> -- 
> 2.20.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Dave Airlie April 24, 2019, 8:16 p.m. UTC | #2
On Thu, 25 Apr 2019 at 05:35, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Wed, Apr 24, 2019 at 11:56:16AM -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.  Propose a clarification here to see if Dave
> > Airlie agrees.
> >
> > Signed-off-by: Eric Anholt <eric@anholt.net>
> > ---
> >
> > Personally, I thought the rule was "has to be in drm-next", but
> > assuming our review processes aren't totally broken, this should be
> > enough.
>
> Yeah if you end up with a revert on your hands the process failed much
> harder and you get to keep the pieces no matter what. Not sure we should
> clarify whether you need a stable sha1 or not (helps with cross
> referencing uapi header updates), but imo good as is. And matches what
> I've been doing/recommending past few years.
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> >
> >  Documentation/gpu/drm-uapi.rst | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > index c9fd23efd957..8e5545dfbf82 100644
> > --- a/Documentation/gpu/drm-uapi.rst
> > +++ b/Documentation/gpu/drm-uapi.rst
> > @@ -92,8 +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
> > +  but it **must** be merged to the driver's -next tree (as documented in
> > +  MAINTAINERS) **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.

I'd rather restrict this to drm-next and drm-misc-next, I frankly
don't trust driver trees here to have the review practices in place.

I trust drm-misc-next to have at least had someone unrelated look over
the new api.

Dave.

Patch
diff mbox series

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index c9fd23efd957..8e5545dfbf82 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -92,8 +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
+  but it **must** be merged to the driver's -next tree (as documented in
+  MAINTAINERS) **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