This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
dev:merge_process [2008/06/19 04:45]
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:development_team | here]] The list of module and library owners and maintainers can be found [[dev:development_team | here]]
 ===== 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/library owner and get in touch with them over email. You can find the list [[here]]
 +  * 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's basically a long, tedious process.
 +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++'s Compare plugin works well for assisting this.
 +  * Merge all co-dependent changed files together.
 +  * Tidy-up the code to meet Sahana formatting guidelines & spellchecks
 +  * Test
 +NB I assume that 'Architectural fit' has been dealt with by the mentor(s)
 +  * 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

QR Code
QR Code dev:merge_process (generated for current page)