With Eric's patch
commit ba6e798ecf320716780bb6a6088a8d17dcba1d49 Author: Eric Anholt eric@anholt.net Date: Wed Apr 24 11:56:17 2019 -0700
drm/doc: Document expectation that userspace review looks at kernel uAPI.
there's been concerns raised that we expect userspace people to do in-depth kernel patch review. That's not reasonable, same way kernel people can't review all the userspace we have. Try to clarify expectations a bit more.
Cc: Eric Anholt eric@anholt.net Cc: Pekka Paalanen ppaalanen@gmail.com Cc: contact@emersion.fr Cc: wayland-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter daniel.vetter@intel.com --- 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 05874d09820c..f368e58fb727 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -85,9 +85,9 @@ leads to a few additional requirements: - The userspace side must be fully reviewed and tested to the standards of that userspace project. For e.g. mesa this means piglit testcases and review on the mailing list. This is again to ensure that the new interface actually gets the - job done. The userspace-side reviewer should also provide at least an - Acked-by on the kernel uAPI patch indicating that they've looked at how the - kernel side is implementing the new feature being used. + job done. The userspace-side reviewer should also provide an Acked-by on the + kernel uAPI patch indicating that they believe the proposed uAPI is sound and + sufficiently documented and validated for userspace's consumption.
- The userspace patches must be against the canonical upstream, not some vendor fork. This is to make sure that no one cheats on the review and testing
On Tue, 21 May 2019 10:48:49 +0200 Daniel Vetter daniel.vetter@ffwll.ch wrote:
With Eric's patch
commit ba6e798ecf320716780bb6a6088a8d17dcba1d49 Author: Eric Anholt eric@anholt.net Date: Wed Apr 24 11:56:17 2019 -0700
drm/doc: Document expectation that userspace review looks at kernel uAPI.there's been concerns raised that we expect userspace people to do in-depth kernel patch review. That's not reasonable, same way kernel people can't review all the userspace we have. Try to clarify expectations a bit more.
Cc: Eric Anholt eric@anholt.net Cc: Pekka Paalanen ppaalanen@gmail.com Cc: contact@emersion.fr Cc: wayland-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter daniel.vetter@intel.com
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 05874d09820c..f368e58fb727 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -85,9 +85,9 @@ leads to a few additional requirements:
- The userspace side must be fully reviewed and tested to the standards of that userspace project. For e.g. mesa this means piglit testcases and review on the mailing list. This is again to ensure that the new interface actually gets the
- job done. The userspace-side reviewer should also provide at least an
- Acked-by on the kernel uAPI patch indicating that they've looked at how the
- kernel side is implementing the new feature being used.
- job done. The userspace-side reviewer should also provide an Acked-by on the
- kernel uAPI patch indicating that they believe the proposed uAPI is sound and
- sufficiently documented and validated for userspace's consumption.
- The userspace patches must be against the canonical upstream, not some vendor fork. This is to make sure that no one cheats on the review and testing
Thank you for clarifying this. I can work with that.
Reviewed-by: Pekka Paalanen pekka.paalanen@collabora.com
Thanks, pq
On Tue, May 21, 2019 at 12:07:12PM +0300, Pekka Paalanen wrote:
On Tue, 21 May 2019 10:48:49 +0200 Daniel Vetter daniel.vetter@ffwll.ch wrote:
With Eric's patch
commit ba6e798ecf320716780bb6a6088a8d17dcba1d49 Author: Eric Anholt eric@anholt.net Date: Wed Apr 24 11:56:17 2019 -0700
drm/doc: Document expectation that userspace review looks at kernel uAPI.there's been concerns raised that we expect userspace people to do in-depth kernel patch review. That's not reasonable, same way kernel people can't review all the userspace we have. Try to clarify expectations a bit more.
Cc: Eric Anholt eric@anholt.net Cc: Pekka Paalanen ppaalanen@gmail.com Cc: contact@emersion.fr Cc: wayland-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter daniel.vetter@intel.com
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 05874d09820c..f368e58fb727 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -85,9 +85,9 @@ leads to a few additional requirements:
- The userspace side must be fully reviewed and tested to the standards of that userspace project. For e.g. mesa this means piglit testcases and review on the mailing list. This is again to ensure that the new interface actually gets the
- job done. The userspace-side reviewer should also provide at least an
- Acked-by on the kernel uAPI patch indicating that they've looked at how the
- kernel side is implementing the new feature being used.
- job done. The userspace-side reviewer should also provide an Acked-by on the
- kernel uAPI patch indicating that they believe the proposed uAPI is sound and
- sufficiently documented and validated for userspace's consumption.
- The userspace patches must be against the canonical upstream, not some vendor fork. This is to make sure that no one cheats on the review and testing
Thank you for clarifying this. I can work with that.
Reviewed-by: Pekka Paalanen pekka.paalanen@collabora.com
Merged with Eric's irc-ack, thanks everyone for helping improve this text. -Daniel
On Tuesday, May 21, 2019 11:48 AM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
With Eric's patch
commit ba6e798ecf320716780bb6a6088a8d17dcba1d49 Author: Eric Anholt eric@anholt.net Date: Wed Apr 24 11:56:17 2019 -0700
drm/doc: Document expectation that userspace review looks at kernel uAPI.there's been concerns raised that we expect userspace people to do in-depth kernel patch review. That's not reasonable, same way kernel people can't review all the userspace we have. Try to clarify expectations a bit more.
Cc: Eric Anholt eric@anholt.net Cc: Pekka Paalanen ppaalanen@gmail.com Cc: contact@emersion.fr Cc: wayland-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter daniel.vetter@intel.com
This LGTM, thanks for the patch! One tiny nit below, but regardless of whether it's changed or not:
Reviewed-by: Simon Ser contact@emersion.fr
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 05874d09820c..f368e58fb727 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -85,9 +85,9 @@ leads to a few additional requirements:
- The userspace side must be fully reviewed and tested to the standards of that userspace project. For e.g. mesa this means piglit testcases and review on the mailing list. This is again to ensure that the new interface actually gets the
- job done. The userspace-side reviewer should also provide at least an
- Acked-by on the kernel uAPI patch indicating that they've looked at how the
- kernel side is implementing the new feature being used.
- job done. The userspace-side reviewer should also provide an Acked-by on the
- kernel uAPI patch indicating that they believe the proposed uAPI is sound and
- sufficiently documented and validated for userspace's consumption.
Nit: "and" is repeated twice (maybe that's intentional?)
- The userspace patches must be against the canonical upstream, not some vendor fork. This is to make sure that no one cheats on the review and testing
-- 2.20.1
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Daniel Vetter -
Pekka Paalanen -
Simon Ser