1 / 12

Software Process

Software Process. Author: Laurence Field (CERN). Terminology. Component The smallest self-contained package (e.g. one rpm) Subsystem A logical group of components (e.g. R-GMA, WMS) Globus, Condor etc considered to be subsystems. The Software Spectrum. CVS. Project Web Page. Project

amie
Download Presentation

Software Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Process Author: Laurence Field (CERN)

  2. Terminology • Component • The smallest self-contained package (e.g. one rpm) • Subsystem • A logical group of components (e.g. R-GMA, WMS) • Globus, Condor etc considered to be subsystems. Laurence.Field@cern.ch

  3. The Software Spectrum CVS Project Web Page Project Repository OS Repository Build System Operating System Externals Packages External Middleware Internal Middleware Service Type Node Type Laurence.Field@cern.ch

  4. Software Distribution • Must integrate at package level • Not everything is available from CVS • For internal code • One CVS directory per component • Package x_y_z = CVS release tag component_R_x_y_z • Require configuration lists per OS for • Repository • Baseline packages • Service Type configuration-> metapackage • Example Node Type configuration-> metapackage • Repository structure • OS -> OS dist rep • Baseline • Updates • Security-updates • CA • Check pointing • Updates move into baseline • Negligible impact on sites Laurence.Field@cern.ch

  5. Bug Submission Users Site Admin Developer Find Problem Integrator Tester GGUS Find Problem TCG Human Filter Feature Request Realistic Feedback Savannah Initiation SA3 endorsement Track Bug Shopping Priorities Release Manager EMT Suggestion Request Fix Laurence.Field@cern.ch

  6. Submission Walkthrough • All middleware bugs tracked in Savannah • Including feature requests • New bugs from many places • Filtering via GGUS for user and sys admin bugs • EMT • Gives realistic feedback on bugs • Priorities discussed • Criticality of update vs development schedule • Timelines assed • TCG requests new features • SA3 shops around for solutions • Proposal given to TCG to endorse • Request given to the release manager to track • Coordination by release manager Laurence.Field@cern.ch

  7. Bug States [rejected] Assigned Duplicate [automatic] Open [accepted] Won’t Fix Accepted Invalid In Progress Ready for Release [open patch] [pass] Fixed Ready For Test Close [fail] Laurence.Field@cern.ch

  8. Bug Walkthrough • Bugs automatically assigned • To subsystem mangers • Subsystem manager accepts or rejects bug • and assigns to developer • Developer investigates and checks fix into CVS • Developer assigns bug to subsystem integrator. • Subsystem integrator releases subsystem/component • Tags CVS with a release tag (component_R_x_y_z) • Creates a Patch. • Adds all required information • Links all the bugs to the patch. • Puts Bug into state “Ready for Test”. • Monitor “Ready for Test” • Close bug when verified • See linked patch for state of fix in the process. Laurence.Field@cern.ch

  9. Patch States Ready For Certification In Certification Open [fail] [pass] Certified In Pre Production Rejected [fail] [pass] In Production Obsolete Not Supported Close Laurence.Field@cern.ch

  10. Patch Walkthrough • Integration team receives new patch. • CVS release tag • Baseline to build against • Linked bugs • Build release tags • Ensure that packages have been created • Move patch to “Ready for Certification” • Release manager pulls patches. • Repository updated • Patch moves to “In Certification” • Patch is certified or rejected • Patches can go to straight Production or via PPS. • Production updates must go to PPS in parallel Laurence.Field@cern.ch

  11. Final Discussions • The Baseline contains a core. • Analogous to the kernel and gcc for linux distribution • Changes of the core will require a new release • Only the core should change • Don’t add any extra functionality • “Developers Playground” • Preview access to next release (core) • Certification should be efficient • To enable trivial updates to move through quickly • Virtual Machines should help to achieve this • Every service should publish its service version • Currently being worked on • Submit bugs against services that don’t provide this • Meta-package must also be versioned • Version change when dependencies change • Meta-package version != service version Laurence.Field@cern.ch

  12. Final Discussions • Need to define checklist • Add extra things to patch submission • Reject patches that do not meet requirements • Need to announce the new process • This is the SA3 announcement  • Update the developers guide • Announce update • Software Process milestone • Points to developers guide Laurence.Field@cern.ch

More Related