Re: [PATCH RFC] dt: bindings: submitting patches document

[Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>]

On 06/11/2013 18:32, Jason Cooper :
> Signed-off-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
> ---
> All,
>
> Since I've now had to answer this question a couple of times, I thought it
> might be worth trying to put it in a document.  I don't like long documents, so
> this is pretty concise, and most likely wrong.  Hence, RFC.  :)
>
> I also dislike quoting people from my imperfect memory, much better to have an
> agreed upon document we can point people towards.
>
> thx,
>
> Jason.
>
>   .../devicetree/bindings/submitting-patches.txt     | 52 ++++++++++++++++++++++
>   1 file changed, 52 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/submitting-patches.txt
>
> diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt
> new file mode 100644
> index 000000000000..5a84d5ebb0f5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/submitting-patches.txt
> @@ -0,0 +1,52 @@
> +
> +  Submitting devicetree (DT) binding patches
> +
> +I. For patch submitters
> +
> +  0) Normal patch submission rules from Documentation/SubmittingPatches
> +     applies.
> +
> +  1) The Documentation/ portion of the patch should be a separate patch
> +     and clearly labelled as such.  For example:
> +
> +       [PATCH X/Y] dt: binding: mvebu mbus driver
> +
> +     This makes the binding portion easy to find among large patch series.
> +
> +  2) Submit the entire series to the devicetree mailinglist at

This is not what I understood.
It seems that we said that only the patch that was containing the 
binding documentation have to be sent to the devicetree mainling-list 
(but this patch being part of a patch series anyway). This way the 
devicetree maintainers would not have to deal with the patch review 
process, even if they can have a look to the code source on the 
mailing-list archive if they need to.

Someone to clarify?


> +       devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +
> +II. For sub-system maintainers
> +
> +  1) If you aren't comfortable reviewing a given binding, reply to it and ask
> +     the devicetree maintainers for guidance.  This will help them prioritize
> +     which ones to review and which ones are ok to let go.
> +
> +  2) If you are comfortable with the binding, and it hasn't received an
> +     Acked-by from the devicetree maintainers after a few weeks, go ahead and
> +     take it.
> +
> +  3) For a series going though multiple trees, the binding patch should be
> +     kept with the driver using the binding.
> +
> +III.  General binding rules
> +
> +  1) Don't hold up a binding because it isn't perfect.
> +
> +  2) Use specific compatible strings so that if we need to add a feature (DMA)
> +     in the future, we can create a new compatible string.
> +
> +  3) Ideally, all bindings receive sufficient review.  In the real world, we
> +     need to prioritize.  Bindings for a specific block of IP aren't as
> +     critical as a binding for a common subsystem, like PCI.
> +
> +  4) Don't submit bindings for staging or unstable.  That will be decided by
> +     the devicetree maintainers *after* discussion on the mailinglist.
> +
> +IV. Notes
> +
> +  This document is intended as a general familiarization with the process as
> +  decided at the 2013 Kernel Summit.  When in doubt, the current word of the
> +  devicetree maintainers overrules this document.  In that situation, a patch
> +  updating this document would be appreciated.
>


-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html