This section contains a set of 'Developers' Use Cases' proposed by software developers in their day-to-day work with ETICS. For each Use Case a definition is given followed by an execution example when known or a short summary of the current status of the use case implmentation

Use Cases List

  1. Adding a new version of an existing component when the new code is in the local workspace and execute a build before committing the changes
    1. If the component is checked out from CVS/SVN and the modifications are already in the workspace, it is directly possible to build the component without any special change in its ETICS configuration
    2. If the component is checked out from the online Repository into the local repository cache and the new version follows the standard ETICS conventions, it is enough to define the new configuration (this works also for the previous case). The recommended steps are as follows:
      1. etics-workspace-setup
      2. etics-get-project <projectname>
      3. etics-checkout -c <oldconfig> <modulename>
      4. etics-configuration prepare -o <modulename>.ini -c <oldconfig> <modulename>
      5. <edit the ini file changing the name, version number, the tag, etc>
      6. etics-configuration modify -i <modulename>.ini --noautocommit
      7. etics-build -c <newconfig> <modulename>
    3. If the component is checked out from the online Repository into the local repository cache, but the new version is in a custom location, it is necessary to define a new configuration and use command-line properties for the location. The recommended steps are as follows:
      1. etics-workspace-setup
      2. etics-get-project <projectname>
      3. etics-checkout -c <oldconfig> <modulename>
      4. etics-configuration prepare -o <modulename>.ini -c <oldconfig> <modulename>
      5. <edit the ini file changing the name, version number, the tag, etc>
      6. etics-configuration modify -i <modulename>.ini --noautocommit
      7. etics-build -p <modulename>.location=<path> [-p <modulename>.buildType=<src|bin>] -c <newconfig> <modulename>
  2. Adding a new external dependency to a package in the local configuration and executing a build before committing the changes
    1. If the new dependency configuration already exists in ETICS, it is necessary to modify the package configuration, merge the dependency in the local workspace and then build the package. The recommended steps are as follows:
      1. etics-workspace-setup
      2. etics-get-project <projectname>
      3. etics-checkout -c <oldconfig> <modulename>
      4. etics-configuration prepare -o <modulename>.ini -c <oldconfig> <modulename>
      5. <edit the ini file adding the dependency>
      6. etics-configuration modify -i <modulename>.ini --noautocommit
      7. etics-checkout --merge [--fromsource|--frombinary] -c <dependency-configname> <dependency-modulename>
      8. etics-build -c <newconfig> <modulename>
    2. If the new dependency configuration doesn't exists in ETICS, it is not currently possible to use the previous method, since it is not possible to add a new configuration for a component in a different project than the current one. This use case can be solved by adding an existing configuration and modifying it, using a package installed in the local repository or command line properties and a package installed in a custom location (as in the cases 1.b and 1.c respectively):
      1. etics-workspace-setup
      2. etics-get-project <projectname>
      3. etics-checkout -c <oldconfig> <modulename>
      4. etics-configuration prepare -o <dependency-modulename>.ini --project <dependency-projectname> -c <dependency-configname> <dependency-modulename>
      5. <edit the ini file changing the name, version number, the tag, etc>
      6. etics-configuration modify -i <dependency-modulename>.ini --noautocommit
      7. etics-build -p <dependency-modulename>.location=<path> [-p <dependency-modulename>.buildType=<src|bin>] -c <configname> <modulename>
  3. Tracing configuration changes. Only the current version of a module can be checked out, there is no way of reverting back, checking changes, testing changes locally prior to committing, etc.: Since configurations are stored in the DB, it is always possible to revert back by re-checking out a configuration. In the same way, it is possible to work on local changes before committing (see the use cases at the beginning of the list)
  4. Fast Development Builds. There is no way for us to let Etics update and build only those modules that have changed. Since a Build takes quite a long time and a programmer (as opposed to an integrator) needs to run a build several times a day, speeding things up would be a real time-saver: by default ETICS only updates and builds only modules that have changed, although it has to replay the build sequence to resolve properties and dependencies. We believe the real issue is the poor performance, which we are working on with top priority
  5. Tagging. There is an etics-tag command but it seems that it does not offer all the features we would require. We need to be able to check up on changes stored in the CVS since the last release tag, specify version changes, create new configurations, and commit): the etics-tag command does almost exactly what you describe here. We need to know what exactly is missing.
  6. Use branch configurations for releases: this is not an ETICS problem. You can use CVS branch tags for defining configurations. This is a gLite integration process requirement
  7. Cross-Branch Use. We need to test certain module/subsystem versions against other modules in other (eg. non-standard) versions (such as a branch version of LB against the head version of VOMS). Is there an easy way to do that? This has to be discussed in some details. Some of this can be done, but this is probably the most difficult case
  8. Building off-line: as far as we can see, it is possible to build off-line without any problem. Of course it is necessary to have checked out all components while on-line before disconnecting. What is missing? What is the problem?
  9. Using software installed locally instead of repository versions: this feature has been implemented and will be released soon. However, it only works with packages installed using relocatable RPMS otherwise is not possible to know where the files are located. Additionally, we would like to understand better what is the requirement here, since checking out packages from the repository is completely transparent and has no side effects, except using some disk space. Please note that using software installed locally doesn't remove the requirement for having the configuration registered in ETICS, since the metadata is required for ETICS to work
  10. Missing debugging symbols in RPMs builds: in the TODO list, should be done before the end of the year
  11. Remote build. We have the impression they frequently don't work as opposed to local builds, caused by remote build machine inconsistencies and, reportedly, repository inconsistencies: as far as we know, there have been no cases of builds working locally and not working remotely with the same configurations and build options. The problem reported about the corrupted libtool script is an SLC4 issue, that is not specific to the remote build nodes, but to any standard SLC4 installation. We need more details about specific cases in order to work on this. Also the word frequently is quite worrying. How frequently does this happen? What are the repository inconsintencies? Since the repository is the same for local and remote build, the inconsistencies should affect both types of builds in the same way.

-- AlbertoDiMeglio - 23 Oct 2007

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r5 - 2007-10-24 - AlbertoDiMeglio
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    ETICS All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback