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/11 18:21] chamindra |
dev:merge_process [2009/07/06 20:36] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ===== Recommended | + | ===== Merge Strategy |
__Assumptions__ | __Assumptions__ | ||
- | * 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. | + | * Unlike a release branch the deployment customizations might have enhancements (release branch only has bug fixes) |
- | * Unlike a release branch the deployment customizations might have | + | * 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 |
- | enhancements (release branch only has bug fixes) | + | * 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 seems not likely to happen. |
- | * Keeping track of your changes in one branch to apply it to the | + | * Automated merging cannot be trusted especially with a large diff between the deployment branch and the trunk. Also the deployment branch might have customizations you do not want to see in the trunk. Thus the only option is manual merging. |
- | 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/ |
- | * 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. | + | |
- | * 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/ | ||
- | * Use a visual merge tool (dedicated to the task of merging) to make | ||
- | it easier. I am using meld ( http:// | ||
- | * Each module/ | ||
- | diffs and then merge what is relevant back into the trunk. | ||
- | * We need to assign a list of module/ | ||
- | are covered. Also they are the best people to know which merges are | ||
- | relevant. | ||
- | * 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/ | ||
- | the bug/ |