On Tue, Sep 01, 2015 at 01:24:17PM -0500, Rob Herring wrote: > 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. I don't want to discount the value of interested people getting together f2f to review these and potentially clean them up for submission. That depends on what we thinking is the minimal "in progress" conversion that can be place upstream. i.e. is it simply compatible strings autoconverted to tags and the entire current document in comments? > > 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). > Were you thinking that this automated conversion would be sufficient for an initial commit? I'm not sure if I misunderstood in your separate comments and was looking at this as something that would be hand edited to move the existing doc (# prefix) into description tags where appropriate. > 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. If we add .yaml in place we can identify what's in progress by the fact that a .yaml exists with the same filename and then based on which tags have been populated (such as type: and constraints: not yet populated) then we know the state. -Matt -- 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
