Posted by indytechcook on June 13, 2012 at 2:38pm
Last updated by indytechcook on Mon, 2012-07-23 13:59
Last updated by indytechcook on Mon, 2012-07-23 13:59
Development will follow the Drupal.org process with a few changes
General Guidelines
- All tasks will be on Drupal.org
- All code will be a patch before it's committed
- All patches must include tests (See testing methodology)
- Keep issue summary updated to reflect what the code is * really doing
- Keep related issue links in the issue summary
- All functions should have document blocks
- Summary
- Purpose
- How to use it
- @params
- @return
- Use Readme files to talk about how the code fits together
- Create *.api.php files for full code examples
- Create a branch for your issue if it is going to be multiple time or patches
Patch Process
This only applies if you are using a seperate branch for development.
- Create the patches against 7.x-1.x branch.
- Any futher patches should have both the patch against the 7.x-1.x branch and the patch with the diff of the branch.
- Name the patches to apply against the 7.x-1.x with *.patch. Name the patches agasing the branch as *.interdiff.
- The file name difference will help when we turn on automated testing.
- Once the ticket is complete, set to RTBC assign back to indytechcook to review and merge the branch into the 7.x-1.x branch.
Issue Tags
Use of Tags: http://drupal.org/node/1023102
- All issues should have an "lsd-csi" tag. This includes any related issue in other projects.
- Sprint tags: "lsd-csi sprint 1"
- "lsd-csi blocker" tag used if the issue is completely blocked. Be sure to update the issue summary about why the issue is blocked
- "lsd-csi community" tag is used for issues which are good candidates for community involvement.
- Issue summary lists can be made using RSS feeds. Links will be kept on the CSI GDO home page.