LWG Minutes 2014-11-18
NOTE: This meeting was in person in New Orleans during the week of SC'14. Thanks to Paul Sathis for taking notes at this meeting.
Discussion about development processes
Chris Morrone suggested the following changes to the development process:
- Drop the word "Feature" from "Feature Releases"
- Start using topic branches and merge topics/features into Lustre's main development branch (master) only when the topic/feature is _done_, fully reviewed, documented, tested, etc. (This is in contrast to the current method where parts of a topic/feature are cherry-picked individually at different times, so topics/features land unfinished and largely untested)
- Change development release cadence from 6 months to 3 months to reduce the impact of missing
the landing window for a release (because we will start allowing merges only when the topic/feature is _done_).
Start focusing on testing a feature _before_ is lands to the main branch and causes destabilization, which impacts all other development that is based on master..
Just have Development Releases not named Feature Release. Like Linux releases: there is a short window at the beginning of the cycle called the "merge window". The feature is either really ready in the window, or else it needs to wait for the next merge window. Calling releases "Feature Releases" always encouraged us to rush completion of features, often landing them with many bugs and other technical debt.
There was a diversion while folks thought that Chris has suggested that there no longer be Maintenance Releases. He clarified that he was not suggesting any such thing. His suggestion was limited to the master branch, and did not necessarily effect the maintenance branches and releases.
More frequent Releases on master does have timing and vendor / version coordination issues. You could force the “must test” rule without eliminating Feature releases. Not everyone has the resources to test – they may want to hang back and let others. Cray and ORNL felt the speed up may require too much testing to get approved? Some shared that Maintenance releases are what people are really using. There are brand new testing methods in 2.7. Use of Hyperion for testing - not always at scale – but used often. Cray is trying to get their scaling test suite released outside of Cray.
Result of discussion:
- General Agreement reached to change the name of releases on the master branch from "Feature Releases" to "Development Releases".
- General Agreement that we should begin merging topic/feature branches and enforcing that the topic or feature is truly complete before merging is permitted.
Someone asked for updates on OpenSFS outstanding contracts.
Chris pointed him towards http://wiki.opensfs.org/Contracts, and then gave a short summary:
CLIO going well, PAC in place. Protocol Documentation project nearing end of discussions. Data on MDT - done Enhanced Layout - done Replication – done DNE and LFSCK – Almost done
Various: How does a new developer to Lustre get spun up? – Answer: OpenSFS project page is relatively up to date.
OSFS Board has talked about Developer Guide. Could we take a bug and break it down to go through the steps – even if we already had the answer ahead? Both debugging and submission aspects. UC Santa Cruz is doing a class on Open Source SW and the students do actual contributions. Our mailing list. Questions from less active community. These discussions should start going to Lustre.org now that OSFS will have that domain. Lustre Developer Forum in Livermore next year. Format? Action: Jump on the mailing list and lets figure it out!!