-
Notifications
You must be signed in to change notification settings - Fork 0
Developers
This is where to go for developer information. Learn how to build, test, and contribute to the project here.
The development cycle and its policies are found in Development Policies.
We use common git practices for our development. We also take advantage of Github web based tools to ease our process.
This is an active project and we are feeling the growing pains of an expanding developer community. The server is also being embedded in commercial products. As a result, our process is becoming more formal. Our workflow is blatantly stolen from the Linux kernel community. They are very good at it and have had 20+ years to get it (mostly) right. The short form steps are:
- The submitter writes some new code or fix some old code...
- Send a pull request to The mailing list.
- The maintainer(s) for the particular subsystem reviews the change.
- The maintainer works with the submitter to get a correct and appropriate change.
- Once the change meets the maintainers approval, the maintainer cherry-picks the commit to their push list and adds their Sign-off-By.
- The release manager pulls the accumulated changes and merges an update to the source tree.
- The release manager pushes periodic updates to the master repository on Github.
- Every update push has a named, annotated tag which contains a comment describing the total merge.
- Both the branch and tag are pushed to the master repository.
- An announcement containing the short log and annotation comment along with more detailed comments (as appropriate) is sent to the Mailing List
- Rinse and Repeat.
Subsystem maintainers are a key part of the process. Their job is to provide review feedback to submitters, make the changes from multiple contributors all fit together, and to aggregate submissions into a coherent whole for clean merge into the tree.
A maintainer is not in the process to just get in the way or add overhead and this does not prevent submitters from requesting a pull directly to the release manager when a change is small, isolated, and obvious in its correctness. However, it is more likely that a pull request will make it into the tree if it first goes through the appropriate maintainer(s) simply because they are closer to what is going on in and around that subsystem.
The following table is the current list of subsystem maintainers. These folks were picked because they have contributed to the project the most in these particular areas. Their review and suggestions are important.
| Subsystem | Maintainer | |
|---|---|---|
| Cache Inode, CEPH FSAL, pNFS, LRU | Adam Emerson | aemerson at linuxbox.com |
| DRC/TIRPC, LRU | Matt Benjamin | matt at linuxbox.com |
| SAL/locks | Frank Filz | ffilz at us.ibm.com |
| Anything Vers 1.5.x | Jujjuri Venkateswararao (1.5 release manager) | jvrao at linux.vnet.ibm.com |
| FreeBSD, VFS FSAL | Sachin Bhamare | sbhamare at panasas.com |
| 9P protocol, LUSTRE FSAL, ZFS FSAL | Philippe Deniel | philippe.deniel at cea.fr> |
| VFS pNFS | Boaz Harrosh | bharrosh at panasas.com |
| GPFS FSAL and pNFS | Marc Eshel | eshel at us.ibm.com |
| PROXY FSAL | Max Matveev | makc at gmx.co.uk |
The people in this table have been chosen based on their past contributions in those particular areas. It is not a closed list. We also and always need reviewers and backup maintainers. Volunteers are encouraged.
Everything developer that does not fit a category all its own ends up here...
A weekly phone conference takes place every Thursday at 8:30AM Pacific time (15:30 UTC). An announcement of the weekly call is emailed to the list with the access numbers and agenda attached. Developers involved in the Ganesha community meet at this time and discuss about development's status and futures features. Minutes to these phone call can be found here.