A lot of work has been put into stabilizing Lustre over the years, and we have evolved processes to ensure we maintain the stability that so many sites worldwide now rely on for their site-wide production filesystems. In many sites, when Lustre stops working many millions of dollars of computing equipment sits idle, so stability of Lustre is the top criterion for all development.
The processes described below ensure that careful attention is paid prior to proposed changes being landed, whether the engineer works for Intel or some other community organization.
This presentation by Eric Barton (from SC10) elaborates on these themes.
The community produces feature releases every 6 months. Check the Community Lustre Roadmap to find out when the next one is scheduled. At the beginning of the development cycle, the features that will be included into the upcoming release are decided, and a landing schedule is worked out to ensure that not all of the features try to land in the week before the code freeze. The feature code freeze may be as early as 3 months prior to the release date, depending on the number and scope of features that are to be landed.
Before starting to think about the logistics associated with developing your feature it is imperative to share your plans with the Lustre community before you start work.
You should check the community development wiki to see if anyone is already working on something similar. If someone is then add yourself as a watcher to the JIRA ticket and offer to collaborate.
If you are unable to find a match, then open a new JIRA ticket outlining your plans, including the intended purpose of the development and any initial thoughts on design. Then, mail the lustre-devel mailing list to draw attention to the ticket. This will alert other community members of your intentions and may well result in potential collaborators stepping forward.
If you choose not to do this you may find that you are either duplicating work with someone else, or that your code needs to be reworked to accommodate other changes occurring in the same part of Lustre code.
While features will not be scheduled for landing into a release until they are already close to completion, it is still important that the features themselves be discussed before or during early development. This allows developers to take into account other changes that are being worked on, to avoid conflicts in network protocol changes, code restructuring, and to ensure interoperability between releases.
It is also strongly suggested that you gain experience in the Lustre landing process by fixing one or more bugs for a maintenance release before attempting to tackle writing a Lustre feature. Feel free to ask for suggestions on the lustre-devel mailing list for a suitable bug to get started with.
Community Lustre releases operate to a "train model". The schedule is fixed and will not wait for features that are not ready in time - they are deferred to the next release.
History has shown that a lengthy stabilization period is needed after all features have landed to work through any bugs introduced by the new code that were not caught by normal regression testing. If there is sufficient testing of intermediate development releases at a large enough scale, and the release branch is stable, additional features may be landed as time permits.
For a feature release scheduled for release in month T the schedule is roughly as follows. For more precise dates, keep up to date on the lustre-devel mailing list .
Please alert the community via the lustre-devel mailing list if you need some extra guidance in getting your patch submitted for the release.