OpenWrt Meeting - October 13, 2014

From PRPL
Jump to: navigation, search

Held 3-5pm today in the VIP-SH shared sponsor meeting room.

Attendees: Ian Oliver, Luka Perkov, Zoltan Herpai, Mark Townsley, Imre Kaloz, Felix Fietkau, help w/name?? (Lantiq) Steven Barth, Art Swift, Mathieu Olivari, Olaf Wachendorf, Kathy Giori

The discussion was somewhat structured, somewhat not, so pardon the randomness in my notes. And of course I won't have remembered nor written down nor understood all the conversations equally well, so feel free to reply with comments and corrections.

First I asked what we should talk about during the panel tomorrow. Luka chimed in right away that "OpenWrt is great". :)

  1. OpenWrt code dev recommendation: more semiconductor companies should adopt OpenWrt as their embedded Linux SDK. Focus more energy and collaboration in one place. But don't just use, contribute. Minimize forks.
  2. Push SoC and driver support to the kernel first, then OpenWrt.
  3. Communicate in advance. When there are questions regarding OpenWrt architecture, framework, and significant ideas for change, address the OpenWrt core development team with a request for comment [RFC], before writing a bunch of new code and asking for it to be applied.
  4. Need ecosystem of OpenWrt professional services. To help semiconductor industry customers (ODMs, OEMs) become more comfortable adopting an OpenWrt-based SDK, we need to develop an ecosystem of professional services organizations around it. Product vendors are willing to pay someone else when they need support, but seeking out individual OpenWrt developers is often problematic. Large companies want support from other large companies. They need to depend on others for maintaining a stable and solid distribution. Chip companies don't have all the expertise that product vendors need. And customer support from chip companies is often lacking (unless you are among a handful of tier 1 vendors). So chip companies should not fork and maintain their own custom distro of OpenWrt -- they should adapt to the project and influence from within as much as possible so that a large professional services ecosystem can be grown to support the product vendors.
  5. Semi-conductor companies should upstream their SoCs and drivers. Newbie developers in those companies should begin with writing documentation and work their way into upstreaming.
  6. Both business and engineering teams in large companies need education on the value of open source, upstream kernel development, software licensing, and the value of building upon the fruits of others in a collaborative fashion. As community manager, Eric Schultz could help evangelize with member companies -- train newbies and educate them on how to contribute not just code but also documentation (especially regarding their own products).
  7. Communications logistics. The prplwrt engineering group (PEG) has weekly 1/2 hour conference calls on Friday 8:30pn PST -- not idea for much of the globe. Should we change the time? Should we also change to Google hangouts? (But then harder to call in when not at a computer.) Or should we all jump on an IRC channel at the same time? Or some of each? Calls have been informal and ad hoc so far. Brief syncs to discuss topics of interest. Probably continue with a combo of both approaches, augmented by mailing list discussions.
  8. Package management is getting better. Someone new to core activities, like Mathieu Olivari, would likely be asked to maintain his own packages/trees directly after proving himself. In general there are many packages (and the number continues to grow), so distributed maintenance is a good thing.
  9. Hardware "certification" or a "prpl stamp". What should that mean? Why is it useful?
    1. should require a level of software "openness" that allows the project to continue to run smoothly
    2. need test automation and regression to make sure the platform support doesn't break as things change
    3. such a program would be useful to be able to guide OpenWrt developers toward distro-friendly and development-friendly platforms
    4. Eric start a list of platforms that are readily supported *and* easily obtainable?
    5. QCA has a board farm infrastructure for automated daily regression testing that we could perhaps share so that any individual or large company could join in and setup similar test beds.
  10. Software licensing is tricky biz. Perhaps prpl could guide and train its member companies on both the advantages of open source sw and what type of software licenses are available. QCA uses the ISC license for our upstream Linux Wi-Fi drivers so that the FreeBSD community can also look at and use the source code as needed in their own distro. Use SPDX tags in OpenWrt packaging?
  11. Documentation. Developers need more of it. Chip companies struggle to share it. QCA legal team modified a Linux Foundation template to create an Open Source NDA. It allows sharing of proprietary docs and source and advanced releases of reference hw that cannot be distributed, but allows developers to understand things well enough to make writing open source code much more efficient (and possible in the first place).
  12. Need a common/abstracted switch interface that enables some commonality among chip venders. Base it on swconfig? (bad abbreviation -- can't tell that "sw" means "switch"), or start with DSA, or SSDK, or ... Maybe use QCA8327 GigE switch as a test chip upon which to collaborate.
  13. Bricking routers. Need more advice on test driving firmware without re-writing to flash and possibly bricking the router. IMG uses SD cards. Platform vendors can also enable boot from USB. Include bootloader source packages (e.g., u-boot) just in case.
  14. There's a lot more going on above the kernel. How do we coordinate what new features industry and vendors and developers want? Keep a wish list in prpl? Focus energy, not too many things at once. LXC containers looks like a cool new project.
  15. Development workflow. Want OpenWrt core devs to understand some of the corporate workflow and development processes that are difficult to handle using OpenWrt. QCA has to integrate proprietary package options for example.
  16. Upstream driver support must be continuously maintained, not coded and dropped over the fence.
  17. Value of collaboration. Need better ways to document advantages and explain benefits to businesses.
  18. Instead of forking, semiconductor and prof services companies can create "flavors" -- configuration customization, adding a UI, etc.

Summary: need better documentation sharing (from chip companies especially), more frequent collaborative communication, improved app/platform security, growth in a hw/sw professional services ecosystem around OpenWrt, and more prpl Foundation events to bring us all together. :)