Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dev:merge_process [2008/06/19 04:45] chamindra |
dev:merge_process [2008/09/26 06:24] fran Change attribution style |
||
|---|---|---|---|
| Line 22: | Line 22: | ||
| The list of module and library owners and maintainers can be found [[dev: | The list of module and library owners and maintainers can be found [[dev: | ||
| + | |||
| ===== Merge Process Kickoff Meeting ===== | ===== Merge Process Kickoff Meeting ===== | ||
| Line 33: | Line 34: | ||
| - Nominate point people and Sahana committers who will participate in the merge process | - Nominate point people and Sahana committers who will participate in the merge process | ||
| - Define a brief schedule and milestones for the work | - Define a brief schedule and milestones for the work | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | ===== Merge Process per Bug Fix / Enhancement ===== | ||
| + | |||
| + | __Have Ready__ | ||
| + | |||
| + | * Identify the module/ | ||
| + | * Checkout an updated version of the trunk | ||
| + | * Have a merge tool handy to compare the difference between the trunk and you deployment code base | ||
| + | |||
| + | __Process for Bugs__ | ||
| + | - Identify and isolate Bux Fix in code to merge using the merge tool | ||
| + | - Create a patch for the bug fix | ||
| + | - Register the bug fix in the tracker and attach the patch | ||
| + | - Module owner takes the patch, adds it to the trunk and tests it | ||
| + | - Module owner approves the patch and closes it in the patch tracker | ||
| + | |||
| + | __Process for Enhancements__ | ||
| + | - Document all the changes made to the module and send it to the module owner | ||
| + | - Speak to module owner to identify which fixes in module are relevant | ||
| + | - Create an entire module patch with only the fixes asked by module owner | ||
| + | - Send the patch to the module maintainer | ||
| + | - Module owner adds patch to the trunk, tests it and commits it. | ||
| + | |||
| + | |||
| + | ===== Merge Process for Localization work == | ||
| + | |||
| + | * PO file will be merged into Pootle | ||
| + | |||
| + | ===== Merge Process for GSoC project merges == | ||
| + | |||
| + | Fran: I must confess that I don't have any great technique here...it' | ||
| + | |||
| + | I'd be very happy to hear from others as to better ways of doing this! | ||
| + | |||
| + | I did the merge in stages: | ||
| + | * Have copies of both Trunk & Branch accessible | ||
| + | * Build a list of all files modified by the participants (by asking the participants & looking at CVS View - having a knowledge of the project helps here, of course) | ||
| + | * Add in new files (can't break anything) | ||
| + | * Do a diff of the modified files with the current version in trunk & review | ||
| + | * If there are simply new functions, then add those (again, can't break anything) | ||
| + | * If old functions are deprecated, then grep codebase to see where the function is used & hence other files which need modifying | ||
| + | * If existing functions are modified, sanity check what's happening. - using Notepad++' | ||
| + | * Merge all co-dependent changed files together. | ||
| + | * Tidy-up the code to meet Sahana formatting guidelines & spellchecks | ||
| + | * Test | ||
| + | |||
| + | NB I assume that ' | ||
| + | * not unnecessarily growing the stack of dependencies | ||
| + | * any 3rd party code included is LGPL-compatible | ||
| + | * using existing Sahana APIs rather than writing their own | ||
| + | |||
| + | What I've not yet done, but should really happen is: | ||
| + | * Form validation checks | ||
| + | * Security checks | ||
| + | * Performance optimisation checks | ||
| + | |||
| + | |||
| + | |||
| + | |||
