Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
dev:merge_process [2008/06/11 18:21] chamindra created |
dev:merge_process [2009/07/06 20:36] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ===== Recommended | + | ===== Merge Strategy |
__Assumptions__ | __Assumptions__ | ||
- | 1. Most of the work in deployment customizations are to do with | + | * Most of the work in deployment customizations are to do with localization and customizing modules. |
- | localization and customizing modules. | + | |
- | 2. Unlike a release branch the deployment customizations might have | + | |
- | enhancements (release branch only has bug fixes) | + | |
- | 3. Keeping track of your changes in one branch to apply it to the | + | |
- | other is a hassle for most developers, especially given the time | + | |
- | pressures of a deployment | + | Thus the only option we have is work with the delta we have between a release/ |
- | 4. Though we have recommended the application of fixes to the trunk at | + | |
- | the same time you do it on the branch, this has not happened and is | + | ===== High Level Approach ===== |
- | seems not likely to happen. | + | |
- | 5. Automated merging cannot be trusted especially with a large diff | + | * Use a visual merge tool (dedicated to the task of merging) to make it easier. I am using meld ( http:// |
- | between the deployment branch and the trunk. Also the deployment | + | * Each module/ |
- | branch might have customizations you do not want to see in the trunk. | + | * We need to assign a list of module/ |
- | Thus the only option is manual merging. | + | * Similar to the release cycle we probably need to have a merge cycle to ensure that all the bug fixes, relevant enhancements get back into the trunk. The only way to make the merge a success is if all areas are covered in one hit so we all need to work together on this. |
+ | * Any clear fixes/ | ||
+ | |||
+ | ===== Module and Library Owners/ | ||
+ | |||
+ | The list of module and library owners and maintainers can be found [[dev: | ||
+ | |||
+ | |||
+ | ===== Merge Process Kickoff Meeting ===== | ||
+ | |||
+ | Here is a tentative agenda for the Merge Process Kick-Off meeting | ||
+ | |||
+ | - Review customizations and changes made to Sahana modules | ||
+ | - Identify key components that will be merged back into Sahana trunk | ||
+ | - Localization work | ||
+ | - Define a merge process that will work for everyone | ||
+ | - Nominate point people and Sahana committers who will participate in the merge process | ||
+ | - 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 | ||
+ | |||
- | Thus the only option we have is work with the delta we have between a | ||
- | release/ | ||
- | 1. Use a visual merge tool (dedicated to the task of merging) to make | ||
- | it easier. I am using meld ( http:// | ||
- | 2. Each module/ | ||
- | diffs and then merge what is relevant back into the trunk. | ||
- | 3. We need to assign a list of module/ | ||
- | are covered. Also they are the best people to know which merges are | ||
- | relevant. | ||
- | 4. Similar to the release cycle we probably need to have a merge cycle | ||
- | to ensure that all the bug fixes, relevant enhancements get back into | ||
- | the trunk. The only way to make the merge a success is if all areas | ||
- | are covered in one hit so we all need to work together on this. | ||
- | 5. Any clear fixes/ | ||
- | the bug/ |