# Changes between Version 44 and Version 45 of Developers/Developing Code Changes

Ignore:
Timestamp:
2017-09-22T23:04:31+02:00 (3 years ago)
Comment:

Unmodified
Removed
Modified
• ## Developers/Developing Code Changes

 v44 Until end of 2015, the PI if a given development action was expected to develop the code and its documentation in a development branch, to go through the different validation steps, and to submit it at the end to a reviewer, the positive answer of the review being a prerequisite for a merge into the NEMO reference. \\ Since Merge Party meeting end of 2015, the process has been changed to a more efficient and reliable process, in order to avoid disagreement and a lock at the review step. The sequence described below is presently to be followed for each development of the NEMO System Team's workplan. == Development Procedure === Description A brief overview of the process is given below. subgraph clusterWorkflow { label = "Worflow per action"; peripheries = 0; labeljust = centered;/* labelloc = b */ Actions  [ shape = record, label = " Action A | Action B\n(postponed) | Action C | Action D | Action E" ] Actions  [ shape = record, label = " Action A | Action B\n(cancelled) | Action C | Action D | Action E" ] Workflow [ shape = Mrecord, label = "{ Development Plan | Preview | Coding\n&\nValidation | Review }" ] Branches [ shape = record, label = "Branch A\n(validated) | Branch C\n(dissallowed) | Branch D\n(validated) | Branch E\n(not ready)"     ] Branches [ shape = record, label = "Branch A\n(validated) | Branch C\n(declined) | Branch D\n(validated) | Branch E\n(incomplete)"     ] } }}} Each development action is expected to be described in the yearly workplan including name of PI, and name(s) of {pre,re}viewer(s) === Workplan content Merging back with the trunk is not described here. The yearly workplan is discussed within System Team, submitted to Developer's Committee, and approved by Steering Committee. It must include, for each development action, its motivation, status, main tasks so as a PI, and a previewer (which will also be the reviewer). \\ If needed, previewer can be divided into a "Science Previewer" and a "System Previewer". The name of Previewer should be added only once he did accept the task, and before submission of workplan to Developer's Committee. == Workplan content == Action Workflow The yearly workplan is discussed within System Team, submitted to Developer's Committee, and approved by Steering Committee. It must include, for each development action, its motivation, status, main tasks so as a PI name, and a previewer (which will also be the reviewer) name. If needed, previewer can be divided into a "Science Previewer" and a "System Previewer". The name of Previewer should be added only once he did accept the task, and before submission of workplan to Developer's Committee. === Follow-up #follow == Detailed description of implementation plan and Preview step {{{#!th Once the workplan has been approved, the code development is planned. The PI should create: '''Wiki''' * '''Associated wiki page''' for explanation. Please follow carefully the following indications: }}} {{{#!th '''Ticket''' }}} |- {{{#!td style="vertical-align: top" [[NewPage(id=WPAction, parent=wiki/2017WP, template=WorkPlanAction, placeholder=Wikipage name, button=Create action's wikipage)]] '' '''Reminder for wiki page name''': '{WG or INSTITUTE}-{NUM}_{PIS}-{KEYWORDS}' '' This page will permit to follow the ongoing work through different  steps for explanation Please follow carefully the following indications: * '''Create review page from the root page of the yearly workplan wiki/\${YEAR}WP''' * 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 * (P)Review status This page will permit to follow the ongoing work through different  steps and will go with: }}} {{{#!td style="vertical-align: top" {{{#!html

}}} * A '''linked ticket''' to gather the group discussion. The following fields have to be set in a appropriate way: * ''''Cc': (P)Reviewer(s) and possible follower(s) should be added for further email notification.''' * 'Component': the area the change is being targeted for. * 'Type': 'development branch' * 'Owner': the code developer \\to gather the group discussion. The form should set few fields ('Type': 'Development' and 'Milestone' to current WP) but others fields have to be set in a appropriate way: * 'Cc': add email(s) of people outside NEMO ST for further notification. * 'Component': the area the change is being targeted for. The other fields in the !ticket (e.g. 'Priority', 'Milestone', 'Keywords') should also be set appropriately. The other fields in the ticket (e.g. 'Priority', 'Keywords') should also be set appropriately. 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).[[BR]]The PI is responsible to give all requested details.[[BR]]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) }}} == Start the coding == 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). \\ The 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) === Start the coding 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. * Changes in the reference manual should be also written as soon as possible, and before review process == Review === Review Once your development is completed, PI requests work of Reviewer(s) for scientific or technical correctness. * The documentation is sufficient to understand the code change and its impacts. The 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. The 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).