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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, Nov 07, 2013 at 12:42:12PM +0100, Nicolas Ferre wrote:
> On 06/11/2013 18:32, Jason Cooper :
> >Signed-off-by: Jason Cooper <jason@xxxxxxxxxxxxxx>
> >---
> >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.

And that is the exact reason I wrote this doc.  ;-)  Mark Rutland said
on Friday during the Q&A portion of the DT talk that he wanted to be
able to refer to the code changes that went with the binding doc patch.

I raised my hand and pointed to the elephant in the room, that this was
the exact opposite of what was decided during the mini-summit.  Grant
said to send the whole series since he has better filters now for
finding the binding documentation changes.

Since he isn't the only reviewer, I came up with the 'dt: binding: ...'
subject line to make the patch easier to find and review.

Long story short, we changed our mind on the last day, and as I said in
the comment section, I don't like quoting others from my imperfect
memory.  So, I'd like to have an agreed upon doc.

> Someone to clarify?

Please.

thx,

Jason.


> >+       devicetree@xxxxxxxxxxxxxxx
> >+
> >+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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux