Last modified 3 years ago
These are the working procedures for the METAFOR website
- All development and documentation should derive from a ticket
- Tickets should provide links to related SVN branches and wiki pages
- Development (ie: writing code) should be done via SVN
- Discussion (ie: talking about code) should be done via email, phone, and wikis
- Documentation (ie: recording issues & decisions) should be done via wikis and tickets
- The distinction between "discussion" and "documentation" is intentionally fuzzy; In general, the wiki should be used for notes and interactive discussions while the ticket comments should be used for summaries/conclusions/decisions.
- Ideally, each ticket should relate to a specific set of requirements and use-cases
How to use tickets:
- An issue/task is identified for a particular component and recorded as a ticket.
- An owner for the ticket is identified and they agree to deal with it.
- The owner may populate the ticket with the following initial information (see here for an example):
- a link to the wiki page where discussion/documentation will exist
- a link to the SVN branch where development will exist
- a link to the related METAFOR requirement(s)
- a link to the related METAFOR use-case(s)
- ...work continues...
- Eventually the ticket should be closed; No editing of the wiki pages is allowed while a ticket is closed.
How to use wikis:
- Wiki pages used for documenting tickets should use the ticket number as their name, and they should provide a link back to the ticket. Other wiki pages should have descriptive names.
- Each wiki should have a descriptive title in the header
("integrate the controlled vocabulary into the CIM" is a good title, "document ticket 230" is a bad title). This title is what will be seen in the table-of-contents used throughout the Trac site. - Each wiki should be located appropriately; The following directory structure exists:
wiki/requirements wiki/use-cases wiki/tickets wiki/<top-level-component>
Where the <top-level-components> are: WP1-7 and CMIP5. Additional sub-directories can be added as needed for specific components.
- Where it is not apparent, text on the wiki should be tagged with the author's name like this [Allyn]
- Each wiki should include an index of wiki pages at its end. This can be added by using the following syntax: [[WikiInclude(admin/metaforIndex)]]
The index page for each top-level-component should include links to all relevant requirements, use-cases, and tickets. Here is a particularly good example. (Note that embedded macros should automatically insert links to all relevant tickets, but it's worth double-checking this.)
How to use SVN:
Some guidelines on what to store in SVN when developing the CIM exist here.
basic usage
- Create a branch: svn copy http://metaforclimate.eu/svn/CIM/trunk http://metaforclimate.eu/svn/CIM/branches/testBranch -m "a sample branch" --username allyn
- Checkout that branch to a working copy: svn checkout http://metaforclimate.eu/svn/CIM/branches/testBranch testBranch
- Modify the working copy... Wheee!
- Discuss and document the modifications on wikis/tickets/email/telcos as appropriate
- Commit the working copy back to the branch: svn commit -m "added testFile"
- Notify an administrator that the branch is ready to be merged into the trunk.
merging changes
- Assume that Statler and Waldorf each creates a working copy based on the same branch (as above).
- Statler makes some changes to his working copy and commits them to the branch (as above)
- Waldorf notices a new SVN revision; He diligently incorporates those changes into his working copy: svn update -r <revision>
- Waldorf makes some further changes to his working copy and commits them to the branch (as above).
- Statler ignores those changes and carries on developing his working copy. When he tries to commit his changes SVN checks to see if there is a conflict first. If there isn't then everything proceeds as before. If there is, then Statler has to (with Waldor's help) resolve those conflicts. ( xxdiff works well for this).
- Assume Statler and Waldorf are both working on different branches.
- Waldorf wants to merge the changes in Statler's branch ito his working copy: svn merge http://metaforclimate.eu/svn/CIM/branches/statlers
- He deals with any conflicts (as above)
- He commits his newly-changed working copy back to his branch
backing out changes
- Waldorf does some work and commits his change to a branch
- He realises he made a mistake and wants to undo the change before other people notice
- So he merges it with the previous revision: svn merge -c <older revision> http://metaforclimate.eu/svn/CIM/branches/waldorfsBranch and then commits it to the branch: svn commit -m "backing out changes from revision x" --username waldorf
advanced usage (merging to the trunk)
- Check out the trunk to a working copy (as above) / or make sure an existing working copy reflected the current state of the trunk (using svn switch / svn update)
- Work out which set of revisions to merge into the trunk: svn log --verbose --stop-on-copy http://metaforclimate.eu/svn/CIM/branches/testBranch, this will print out a list of each prior commit of testBranch
- Merge testBranch into the trunk working copy: svn merge -r <start revision>:<end revision> http://metaforclimate.eu/svn/CIM/branches/testBranch (typically, the end revision will be "HEAD" and the start revision will be the last number printed out in the previous step)
- Check the status and deal with any conflicts (as above)
- odds are that when dealing w/ the CIM I will want to just overwrite my working copy with the merged branch, so when a conflict is encountered I can select the option "tf" to accept "theirs-full"
- Commit the working copy back to the trunk: svn commit -m "merged testBranch@<current revision> into trunk" --username allyn
- Once commited, tagging is trivially easy: svn copy http://metaforclimate.eu/svn/CIM/trunk http://metaforclimate.eu/svn/CIM/tags/<my_tag> -m "tagging the CIM for some reason" --username allyn
(the first argument to copy could just as easily be a branch or a working copy if I were tagging for some reason other than a formal release)
Wiki Index
- WP1: the starting point for WP1: Project Management
- WP1/Amendment3: Amendment 3: Metafor project extension
- WP1/SoftwareManagement: Live Deliverables
- WP1/TelcoMinutes: Teleconference minutes
- WP1/TelcoMinutes/20Sept2011
- WP1/TelcoMinutes/Telco138_27Sept2011: Telco 138 - 27th September 2011
- WP1/TelcoMinutes/Telco139_4Oct2011: Telco 139 - 4th Oct 2011
- WP1/TelcoMinutes/Telco140_11Oct2011: Telco 140 11th October 2011
- WP1/TelcoMinutes/Telco141_1Nov2011: Telco 141 1st November 2011
- WP1/TelcoMinutes/Telco142_6Dec2011
- WP1/TelcoMinutes/Telco143_5Jan2012: Telco 143 5th January 2012
- WP1/TelcoMinutes/Telco144_2Feb2012: Telco 144 2nd February 2012
- WP1/TelcoMinutes/Telco145_6Mar2012: Telco 145 6th March 2012
- WP1/TelcoMinutes/Telco146_2Apr2012: Telco 146 2nd April 2012
- WP1/TelcoMinutes/Telco147_10May2012: Telco 147 10th May 2012
- WP2: the starting point for WP2: The CIM
- WP2/ControlledVocabulariesList: A flat list of controlled vocabulary terms for the CIM
- WP2/DevelopingTheCIM: some guidelines for developing the CIM
- WP3: the starting point for WP3: testing/populating
- WP3/Agile: Metafor WP3 Group - Agile Management
- WP3/Agile/Sprints/01: Metafor WP3 Group - Sprint 01
- WP3/docs
- WP3/telcos
- WP3/telcos/03/agenda
- WP3/telcos/04
- WP3/telcos/05: Agenda
- WP4: the starting point for WP4: Services
- WP4/Agile: Services Group - Agile Management
- WP4/Agile/Sprints/01: Services Group - Development Sprint 01
- WP4/Agile/Sprints/02: Services Group - Development Sprint 02
- WP4/Agile/Sprints/03: Services Group - Development Sprint 03
- WP4/Agile/Sprints/03/url-design: Initial Thoughts on Metafor URL design to supplement attached note
- WP4/Agile/Sprints/04: Services Group - Development Sprint 04
- WP4/Agile/Sprints/05: Services Group - Development Sprint 05
- WP4/Agile/Sprints/06: Services Group - Development Sprint 06
- WP4/Agile/Sprints/07: Services Group - Development Sprint 07
- WP4/Agile/Sprints/08: Services Group - Development Sprint 08
- WP4/Agile/Sprints/08/Agenda
- WP4/Agile/Sprints/09: Services Group - Development Sprint 09
- WP4/Agile/Sprints/11
- WP4/Agile/Sprints/12: Services Group - Development Sprint 12
- WP4/Agile/Sprints/19
- WP4/Deliverables
- WP4/MF-ISENES-Timeline
- WP4/NumSim: WP4/NumSim
- WP4/PortalDeployment: pre-requisites
- WP4/QDeployment: Deploying the questionnaire
- WP4/QSandbox: Notes on building questionnaire sandboxes
- WP4/ServicesPlanningDocument: Metafor Services (WP4, WP5, & WP6): Deliverables, Dependencies, and …
- WP4/URIstructure: WP4/URIstructure - The Metafor URI structure(s)
- WP5: the starting point for WP5: Tools
- WP6: the starting point for WP6: CIM Creation
- WP7: the starting point for WP7: Dissemination
- CMIP5: the starting point for CMIP5
- CMIP5/FileMetadata: CMIP5 Internal File Metadata
- CMIP5/QuestionaireBetaTesting: Comments, queries and issues raised by our beta testers
- CMIP5/QuestionaireIssues: Alpha 5 release of the CMIP5 questionnaire: …
- CMIP5/QuestionaireRequirements: CMIP5 questionnaire requirements
- CMIP5/QuestionaireTimeline
- CMIP5/QuestionnaireAccess: Instructions for Access to the CMIP5 Questionnaire …
- CMIP5/QuestionnaireCentres
- CMIP5/QuestionnaireOpenLetter: Open letter to our users
- CMIP5/QuestionnaireTimeline
- CMIP5/Storyline
- CMIP5/VarURIStructure: CMIP5/Variable Structures
- CMIP5_CVSoft
- requirements: METAFOR requirements
- requirements/testRequirement: requirement: make sure that thingies contain widgets (sample requirement)
- use-cases: METAFOR use-cases
- use-cases/AnnotateCIMRecord: Use-Case: Annotate a CIM Record
- use-cases/BrowseCIMRepository: Use-Case: Browse a CIM Repository
- use-cases/CaptureGridDefinition: Use-Case: Capture a Grid Definition
- use-cases/FindCIMRepository
- use-cases/FindExperimentsForModel: Use-Case: Find Experiments Based On Model X
- use-cases/FindModelsForExperiment: Use-Case: Find Models Used In Experiment X
- use-cases/FindModelsToCouple: Use-Case: Find Models To Couple
- use-cases/FindRelatedCIMRecords: Use-Case: Find Related CIM Records
- use-cases/FindRelatedCitations: Use-Case: Find Related Citations
- use-cases/KeywordSearchCIMRepository: Use-Case: Keyword Search a CIM Repository
- use-cases/QueryCIMRepository: Use-Case: Query a CIM Repository
- use-cases/ViewCIMRecord: Use-Case: View a CIM Record
- use-cases/ViewDatasetQualityReport: Use-Case: Find Related Citations
- use-cases/create-qc-record: Use-Case: Modify or Create a quality control record
- use-cases/template: Use-Case: <name>
- use-cases/testUseCase: Use-Case: a sample use-case
- tickets/1008: QC for CMIP5 Questionnaire Records
- tickets/167: CIM sequence document & diagrams
- tickets/180: notes for ticket 180
- tickets/181: notes for ticket 181
- tickets/182: The Wiki page for documenting progress on the ConCIM activity package: …
- tickets/184: Existing Controlled Vocabulary lists
- tickets/185: notes for ticket 185
- tickets/189: Use Cases for interacting with the UMUI Minutes from a meeting that …
- tickets/191: Experiment relationships for CMIP5
- tickets/192: CMIP5 Questionnaire
- tickets/193: Extracting CIM metadata from code and verifying CIM metadata and code are …
- tickets/214: Figure out how the Controlled Vocabulary should integrate with the CIM
- tickets/215: tidy the CIM (as per the Y1 meeting)
- tickets/226: restructure the wiki
- tickets/232: create a widget for the thingie (sample ticket)
- tickets/236: tidy the CIM (to make it less XML specific)
- tickets/237: include sequencing info in the CIM
- tickets/239: Outstanding CIM Issues
- tickets/241: Implement Tree Navigation for the CMIP5 Questionnaire
- tickets/244: Processing the mindmaps (bundled version) to create XML suitable for …
- tickets/245: Work in progress
- tickets/247: Ingest ESG metadata into mindmaps
- tickets/248: CMIP5 Questionnaire Timeline
- tickets/249: Questionnaire to CIM Conversion
- tickets/250: CMIP5 Conformance wiki for ticket #250
- tickets/253: Questionnaire Metadata Validation
- tickets/254: Table 1: CMIP5 constraints not enforced by the Questionnaire
- tickets/277: Proposed updates to the CIM Grid logical data model
- tickets/280: add / revise definitions of terms used in the CIM
- tickets/281: when should references use XPath and when should they embed documents …
- tickets/31
- tickets/326/aerosols
- tickets/326/atmos
- tickets/326/atmos_chem
- tickets/326/land_ice
- tickets/326/land_surf
- tickets/326/ocean: Herafter is the previous version of definitions tables for Ocean, included …
- tickets/326/ocean_biochem
- tickets/326/sea_ice: Herafter is the previous version of definitions tables for Ocean, included …
- tickets/485: CMIP5 Questionnaire
- tickets/509: What Deployment/Hardware/Configuration? Information Should Be Recorded?
- tickets/519
- tickets/55: Metafor Governance
- tickets/636: Wiki Page for Ticket #636 (Review of Grid Properties in MindMaps)
- tickets/684: Discussion of Ensemble Handling Issues
- tickets/707: THREDDS to CIM instances tool
- tickets/709: CIM v1.5
- tickets/715: METAFOR Success Criteria
- tickets/778: Integrate Controlled Vocabularies with the CIM
- tickets/78
- tickets/79: CIM Differencing Tool Design Document
- tickets/810
- tickets/862: Required CIM Software Component Properties
- tickets/868: Some Documentation of Issues associated with ticket:868
- tickets/870: Moving towards CIM2.0
- tickets/888: Definition of unconfigured vs configured model
- tickets/92: Outstanding CIM Prototype Human GUI Issues
- tickets/920: O&M
- tickets/920/options4om1: Initial Step
- tickets/920/sidl: Scientific Interface Definition Language (SIDL)
- tickets/921
- tickets/925: A Common Information Model paired with scientific Controlled Vocabularies …
- tickets/926: EGU abstract - The CMIP5 questionnnaire: web-based metadata collection for …
- tickets/927
- tickets/986: CIM v1.7
