Re: [RFC PATCH 0/5] DT binding documents using text markup

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

 




On Tue, Sep 1, 2015 at 1:03 PM, Tim Bird <tbird20d@xxxxxxxxx> wrote:
> On Tue, Sep 1, 2015 at 10:35 AM, Frank Rowand <frowand.list@xxxxxxxxx> wrote:
>> On 9/1/2015 10:14 AM, Tim Bird wrote:
>>> On Fri, Aug 28, 2015 at 10:13 AM, Matt Porter <mporter@xxxxxxxxxxxx> wrote:
>>
>> < snip >
>>
>>>>
>>>> But to answer your question, if we get a format I'll do
>>>> conversions and hope I'm not alone.
>>>
>>> I'm sure others will help out.  I will, and I'm pretty sure we can get
>>> some conversion sprints set up at conferences (I know I can set aside
>>> some time or resources at ELC in the spring - it might be too late for
>>> ELCE in October to set up a scheduled block of time, but we can start
>>> getting the word out.)  As I said in my other e-mail, one doesn't have
>>> to be a kernel coder to do this, and the conversions should be pretty
>>> straight-forward.
>>>  -- Tim
>>>
>>
>> A conversion sprint at ELCE sounds like a good idea if we can find a
>> good time to schedule it.  I can help, so there will be at least two
>> of us who can help people as they encounter issues.
>
> Even if we don't find a block of time, we can do something like
> announce a "contest", ask people to do something in their spare time,
> and find some way to get them a raffle ticket if they submit a patch
> with a conversion.  Then hold an extra prize drawing during the
> closing session, with just those raffle tickets, and give someone a
> nice award for contributing.  Of course, there's always the adage that
> you should be careful what you measure and reward...  We don't want a
> flood of crappy conversions, with a time constraint on the review.
> I'll think some more about this.  An alternative would be to have a
> contest announced ahead of the event, with enough time for people to
> submit and get reviewed.

Sounds like a review nightmare. That's another reason why as much
automated conversion we can do, the better.

> By the way - I presume the new docs will replace the existing ones,
> but I could imagine wanting to have them live side-by-side
> temporarily.  Any thoughts on this?  Will file name or location
> changes be allowed during the conversion?

I proposed some ideas earlier in the thread. Either we can have both
side by side or do a mass conversion to YAML making the existing doc a
comment (add # prefix).

Any renames/moving should be separate (there's some clean-up I'd like
to there as well). Exact rules depend on the approach, but we need to
be able to tell which bindings conversions are not started, in
progress, or complete.

Rob
--
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