1 / 18

S/W Process: Background

The AstroGrid-D Software Process Hans-Martin Adorf (MPA) Thomas Brüsemeister (ARI) Oliver Wehrens (AEI) Astrogrid WS Heidelberg, 24.07.06. S/W Process: Background. History Task force formed at April ’06 meeting Report due at July ’06 meeting Status

dawn-henson
Download Presentation

S/W Process: Background

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. The AstroGrid-D Software ProcessHans-Martin Adorf (MPA)Thomas Brüsemeister (ARI)Oliver Wehrens (AEI)Astrogrid WS Heidelberg, 24.07.06

  2. S/W Process: Background • History • Task force formed at April ’06 meeting • Report due at July ’06 meeting • Status • Document “Software Process of AstroGrid-D” • Segments covering different aspects • A place for all things to be discussed/decided • Not the “final” standard document

  3. Goal & Objectives • Goal • Make contributing S/W to AstroGrid-D and using it a positive experience • Objectives • Make S/W easily usable on all platforms for AstroGrid-D & other users • Common well-structured repositories • Consistent documentation & unified build scripts • Continuous integration & validation tests

  4. Problems • Problems to overcome • Distributed project • Multiple languages (incl. non-portable ones) • Heterogeneous platforms • No central authority imposing standards/taking technical decisions • Need an efficient decision process (and who is going to decide that?)

  5. Action Items • Action items (in rough order) • Issue tracking • Repositories • Source repository • Release repository • Documentation • Build process • Dependency description • Continuous integration incl. regression tests • Validation tests

  6. How to proceed... • How to proceed? • Not all areas are mature enough for a decision • Collect input from experts: • How to get C/C++/FORTRAN projects to work on heterogeneous platforms? • Plan: proceed in a piecemeal fashion

  7. Issue tracking • Issue tracking • What for? • bugs, feature requests • other (all?) action items • Main contenders: Bugzilla & JIRA • JIRA requires open source license (or money) • Next steps • Send license to JIRA developers • Evaluate JIRA

  8. Source repository • Source repository • All source code that has no other home • Main contenders: CVS & SVN • Task force recommends SVN • VCS structure will be determined by software packages • Next steps • Vote • Install VCS • Formulate policy about its usage

  9. Release repository • Release repository contains all the software in released versions • This can be as simple as a tarball on the public website

  10. Documentation • At minimum: • A README file (simple ASCII) providing a general overview of the package, including a Statement of the internal and external packages (including the version) that it depends on • An INSTALL file (simple ASCII) providing the installation directions. • Code documentation should happen with doxygen and javadoc

  11. Documentation (II) • Apache Maven’s pom.xml provides a nice and easy way to provide a unified look and feel to all web documentation (dependencies, mailing lists, developers, source code repository ... ) • Don’t have to use maven for build process but just can use it for documentation purpose 11

  12. Dependency description • Machine readable dependency description • Makes continuos integration and testing much easier • Maven 2 has a nice model for that defined in a pom.xml 12

  13. Build process • Was asked for a unified build process to easy the installation of AstroGrid-D Software • Cross language build tool • We do favor Maven 2 (again!) • Java based tool • Supposed to work with c/c++ and others but this has not been verified 13

  14. Continuous integration • Continuous integration (CI) is used to make sure the software in the repository compiles and passes defined tests • Several tools are available to do that • Apache Continuum is one possible solution • Overview: http://docs.codehaus.org/display/DAMAGECONTROL/Continuous+Integration+Server+Feature+Matrix 14

  15. Tests • Do we want to do tests for the software itself ? • Do we require that for all software developed by AstroGrid-D ? 15

  16. Action Items • Action items (in rough order) • Issue tracking • Repositories • Source repository • Release repository • Documentation • Unified Build process • Dependency description • Continuous integration incl. regression tests • Validation tests

  17. Vote? • Bugtracking (JIRA, Bugzilla, do people have other experiences)? • Source repository (CVS, SVN) ?

  18. More • Who is going to maintain repositories, build server and does QA on the software to make sure it meets the standards of AstroGrid-D ? • Questions? • Suggestions?

More Related