The AstroGrid-D
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

S/W Process: Background PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on
  • Presentation posted in: General

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


S w process background

The AstroGrid-D Software ProcessHans-Martin Adorf (MPA)Thomas Brüsemeister (ARI)Oliver Wehrens (AEI)Astrogrid WS Heidelberg, 24.07.06


S w process background

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


Goal objectives

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


Problems

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?)


Action items

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


How to proceed

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


Issue tracking

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


Source repository

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


Release repository

Release repository

  • Release repository contains all the software in released versions

  • This can be as simple as a tarball on the public website


Documentation

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


Documentation ii

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


Dependency description

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


Build process

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


Continuous integration

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


Tests

Tests

  • Do we want to do tests for the software itself ?

  • Do we require that for all software developed by AstroGrid-D ?

15


Action items1

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


S w process background

Vote?

  • Bugtracking (JIRA, Bugzilla, do people have other experiences)?

  • Source repository (CVS, SVN) ?


S w process background

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?


  • Login