On 05/05/2016 12:05 PM, Bill Gatliff wrote:

On Thu, May 5, 2016 at 11:50 AM Martin Stadtler <martin.stadtler@linaro.org mailto:martin.stadtler@linaro.org> wrote:

Specifically for the 96boards, the spec is a recommended view, but
its not meant to be constraining, however it does allow one to
then show a best practice, that others can adopt.  That's where
the RPB comes in to play, again to demonstrate and not restrict.

Sorry to jump in on this, since my horse in this race is pretty small...

That whole "best practice" point is REALLY important. But it's more nuanced than just "do it this way":

A. Vendors will do what they do, and they'll have their reasons. If the community offers them a "best practices" guideline, especially one that's easy to adopt (in full or in part), then hopefully they'll be less likely to stray.

B. If that best-practices document offers more than a one-size-fits-all recommendation, then so much the better. Again, it keeps necessary variants closer to the community than they might have been; a partial victory isn't a total loss.

C. (This is my main point.) When I see a document that says "best practices", then I understand that there's no binding requirement per se, and that it's likely that there will be deviations.

D. When that's the case, I'm more likely to produce code that's easily adapted to the various permutations of best-practices that I encounter, often with the blessing of my customer. Doubly so if those variations are predictable.

Otherwise, a customer will tell me to just "code to the requirement"---and that's all they'll pay for. Then my solution isn't likely to be as widely deployable, which cuts off opportunities to recycle that solution back to my point (A), even if the code becomes public.

I can't always code for every possibility. But, with a best-practices guideline that says "if you can do it X way, then do so; if you can't, but you can do Y, that's almost as good; else, for gods' sake don't do Z", I can better plan for where the changes might arise later.

Maybe I won't code the solution for everyone, but I'm likely to get a lot closer than I would have.

One thing I like to see in Best Practices guide is what is the benefit of the following the best practice. From that it is much easier to make the assessment of whether the promised result is worth following the guidance. All of the best practices people here are talking about appear to be geared toward a frictionless connection to the ARM Linux ecosystem. That's something many software focused Linaro participants care about, but is that something manufacturers care about? Usually I only hear about saving pennies leading to profits at scale being a priority. So if we can talk up gaining scale by following the practices, there's a better chance members will listen.