LWG Minutes 2014-10-15

From OpenSFS Wiki
Jump to navigation Jump to search


  • LU-4239
  • Roadmap Update
  • Lustre's future (continued)


  • Chris Morrone (LLNL)
  • Richard Henwood (Intel)
  • Peter Bojanic (Seagate)
  • Andreas Dilger (Intel)
  • Cory Spitz (Cray)
  • James Simmons (ORNL)



Cray reported LU-4239 not getting adequate reviewer attention. Andreas pinged Di to review the patch after seeing Cray's note on the LWG list. James says it needs to have a regresstion test added, and will flag the patch to note that requirement.

Roadmap Update

Andreas suggested Peter Jones would probably be interested in contributing to the update.

Lustre's future discussion

Andreas definitely in favor of what (chris) discussed last week. That OpenSFS spend some fraction of investment in infrastructure improvements. Not a sexy area that any RFP or vendor is going to sink much money into it because there is no feature or measurable speed improvement.

Adding comments is not sexy, but needs to be done.

Dead code remove, static code analysis, code comments all necessary work.

Bojanic asked it the OpenSFS Board sets goals for the year. Chris suggested that we probably need to decide on the goals in the LWG, and present them to the Board for approval (which is basically how things tend to work already).

The next year goals should be on theme of improvement.

Andreas, segue into another topic. Do we have goal for next long term maintenance release? Suggests 2.8 would be possible next maintenance release.

Chris not opposed, but wonders if the development processes and release cadence might have changed by that time, which might make it too early to pick 2.8.

Discussion about release cadence ensued.

LLNL folks are thinking that adopting some characteristics of the Linux kernel model would be good. For instance:

  • Merge topic branches of commits rather than landing commits one by one
  • Topic branch lands only during merge window (1 week?) at beginning of release cycle
    • Code readable & maintainable, not just functional
    • Fully documented
    • Fully tested
    • Fully peer reviewed
  • Shorter, more frequent releases (3 months like Linux kernel?)
  • No more "feature releases". Code lands if ready, waits for next merge window if it isn't. Really follow train model.