Changes between Version 45 and Version 46 of Developers/Developing Code Changes


Ignore:
Timestamp:
2017-09-26T01:38:56+02:00 (3 years ago)
Author:
nicolasmartin
Comment:

Refactoring

Legend:

Unmodified
Added
Removed
Modified
  • Developers/Developing Code Changes

    v45 v46  
    6060== Action Workflow 
    6161 
    62 === Follow-up #follow 
     62=== Follow-up & Development plan 
    6363 
    64 {{{#!th 
     64'''Each action must have a wikipage and a ticket related to it'''. Browse to the current workplan page `wiki/${YEAR}WP` to create them and find the content and status of all planned actions in the workplan. 
    6565 
    66 '''Wiki''' 
     66In addition to the general informations of the action (subject, people involved, resources, ...), the wikipage will describe in details: 
     67* Implementation plan: scientific context with references, code modifications with modules/files/variables and documentation changes (reference manual, wiki, ...) 
     68* Validation results from list of tests to ensure the development produces the anticipated effects and doesn't not impact unexpectedly the operation of the code and its other components, see below 
     69* (Pre,Re)view finding: decision with motivated feedbacks 
     70__Please follow carefully the indications in 'Help' section to avoid issues when editing the wikipage and the form fields__. 
    6771 
    68 }}} 
    69 {{{#!th 
     72The ticket will monitor the progress in the development and so it should be updated as the work goes on. In that regard, the commits with a clear reference to the ticket in the log message (`#XXXX`) will be listed in the 'Commit History' Section. 
    7073 
    71 '''Ticket''' 
     74Once the 1^st^ part of the wikipage is completed by PI (detailed implementation plan), the PI will submit it to Previewer. The Previewer will discuss with PI to reach full agreement on detailed implementation plan (in a maximum of 2 weeks starting from submission date). \\ 
     75The PI is responsible to give all requested details. The Previewer is responsible to check with all experts that implementation plan is indeed correct and compatible with the other developments going on in parallel during the year.  Objective is to avoid the need for a full rewriting at the end (which did happen sometimes previously). 
    7276 
    73 }}} 
    74 |- 
    75 {{{#!td style="vertical-align: top" 
     77=== Coding & Validation 
    7678 
    77 [[NewPage(id=WPAction, parent=wiki/2017WP, template=WorkPlanAction, placeholder=Wikipage name, button=Create action's wikipage)]] 
    78  '' '''Reminder for wiki page name''': '{WG or INSTITUTE}-{NUM}_{PIS}-{KEYWORDS}' '' 
     79==== Start the coding 
    7980 
    80 This page will permit to follow the ongoing work through different  steps for explanation 
    81 Please follow carefully the following indications: 
    82   * '''Create review page from the root page of the yearly workplan `wiki/${YEAR}WP`''' 
    83   * Once this last page is created, you do not need to edit it like a typical wiki page to complete the requested fields: just complete the fields in the writeable areas and click on "Submit" button at the end of the section to save your additions 
    84   * Editing the page is only needed if your want to add some fields in the page. Activate the "side to side" button on top right of the page to facilitate this first edit and '''do not switch to 'wyziwig' view mode''' 
    85   * The wiki page will describe: 
    86     * Purpose, motivation and main tasks of the action 
    87     * PI(S) & (P)Reviewer(s) name(s) 
    88     * Detailed  implementation plan: scientific, technical and an expected summary  of changes for NEMO reference manual to be written later. 
    89     * Detailed list of specific tests, see below 
    90     * (P)Review status 
     81Once the Previewer has sent the green light (approval of development plan), the PI can created the corresponding development branch. This branch should be created from the up to date version of NEMO as chosen for each year (usually the trunk at a given revision, see minutes of NEMO System Team videoconferences or our local NEMO representative). 
    9182 
    92 }}} 
    93 {{{#!td style="vertical-align: top" 
    94    {{{#!html 
    95       <p></p> 
    96       <form action="/nemo/newticket?summary=summary&type=type&version=version" method="get"> 
    97       <input type="hidden" name="type"    value="Development"               /> 
    98       <input type="hidden" name="version" value=""                          /> 
    99       <input type="text"   name=summary size=51 placeholder="Ticket subject"/> 
    100       <input type="submit" value="Open action's ticket"/> 
    101       </form> 
    102    }}} 
     83Development branches will be created on the SVN repository under the directory `svn/nemo/branches/$YEAR`. The pattern for the branch name is: `dev_${forking revision number}_${workplan item}-${keyword(s)}` (ex 'dev_r8329_ENHANCE14_SAL') 
    10384 
    104 \\to gather the group discussion. 
    105 The form should set few fields ('Type': 'Development' and 'Milestone' to current WP) but others fields have to be set in a appropriate way: 
    106 * 'Cc': add email(s) of people outside NEMO ST for further notification. 
    107 * 'Component': the area the change is being targeted for. 
     85==== Develop and document your change 
    10886 
    109 The other fields in the ticket (e.g. 'Priority', 'Keywords') should also be set appropriately. 
     87Development can progress on this new branch. A few things to bear in mind when developing your changes: 
    11088 
    111 }}} 
     89* Follow the appropriate coding standard, see NEMO coding standards document. Code should be documented on line as defined in the coding rules. 
     90* Ensure commit messages to your branch are meaningful, they are visible to everyone using the system. 
     91* Commit regularly and don't wait to have a certain amount of changes to do so, the debugging process will be easier with multiple small modifications by testing each revision one by one. 
     92* Changes in the reference manual should be also written as soon as possible, and before review process. 
    11293 
    113 Once the wiki page is completed by PI (detailed implementation plan), the PI will submit it to Previewer. The Previewer will discuss with PI to reach full agreement on detailed implementation plan (in a maximum of 2 weeks starting when PI submits wiki page to Previewer). \\ 
    114 The PI is responsible to give all requested details. \\ 
    115 The Previewer is responsible to check with all experts that implementation plan is indeed correct and compatible with the other developments going on in parallel during the year.  Objective is to avoid the need for a full rewriting at the end (which did happen sometimes previously) 
    116  
    117 === Start the coding 
    118  
    119 Once the Previewer has sent the green light (approval of detailed implementation plan and summary of changes in reference manual), the PI can created the corresponding  development branch. The branch should be created from the up to date version of NEMO as chosen for each year (usually the trunk at a give fixed revision for a give year, see minutes of NEMO System Team videoconferences.  Development can progress on this new branch. 
    120  
    121 Each year, development branches will be created in the directory `svn/nemo/branches/YEAR/"standard name of dev branch"`.\\ 
    122 `"standard name of dev branch"` should be: `dev_"starting revision number"_"workplan item_purpose"` (ex 'dev_r1302_LOCEAN1_mpp') 
    123  
    124 === Develop your Change 
    125  
    126 A few things to bear in mind when developing your changes, 
    127  
    128  * Follow the appropriate coding standard, see NEMO coding standards document. 
    129  * Ensure commit messages to your branch are meaningful. They are visible to everyone using the system. 
    130  * You don't have to commit to your branch to test a change. You can compile from a working copy. 
    131  
    132 === Test your Change 
     94==== Test your Change 
    13395 
    13496Test your change appropriately and record the results. The testing required will depend on the change and the potential impact on other configurations. When testing, things to consider include 
    13597 
    136  * full successful SETTE tests: to check nothing is broken or goes wrong in the reference configurations SETTE tests: if running with some changes in the results, those have to be justified and checked in detail. New code should not change results when it is switched off, and not alter results when tuned on. 
    137  * full successful specific tests: to be defined before starting, in order to check that development does indeed what is expected 
    138  
    139 ''In particular the Trusting tool has been developed in order to ease the validation all along the working on the code, not all in one with SETTE. The developer can regularly evaluate the changes for a any given configuration compared with benchmark results he has defined.'' 
    140  
    141 === Document your Change 
    142  
    143  * Progress in the development should be documented as the work goes on in the !ticket created at the beginning/ 
    144  * Code should be documented on line as defined in the coding rules 
    145  * Changes in the reference manual should be also written as soon as possible, and before review process 
     98* full successful SETTE tests: to check nothing is broken or goes wrong in the reference configurations SETTE tests: if running with some changes in the results, those have to be justified and checked in detail. New code should not change results when it is switched off, and not alter results when tuned on. 
     99* full successful specific tests: to be defined before starting, in order to check that development does indeed what is expected 
    146100 
    147101=== Review 
     
    151105The reviewer should check that th development did indeed meet what has been approved at Preview step 
    152106 
    153  * The code changes are understood and appropriately made. 
    154  * The documentation is sufficient to understand the code change and its impacts. 
     107* The code changes are understood and appropriately made. 
     108* The documentation is sufficient to understand the code change and its impacts. 
    155109 
    156110The Reviewers completes the review part of wiki page with the PI. Once all light are green, the development is approved and can be merged for the new release of NEMO (merging back with the trunk is not described here).