| Message ID | 20190424185617.16865-1-eric@anholt.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] drm/doc: Allow new UAPI to be used once it's in the driver's -next. | expand |
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
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.
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
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(-)