How to get something into the gLite release
Background
This document is intended to aid those contributing to gLite. It is not intended for those (such as JRA1) maintaining core services, but rather for
someone wishing to contribute a utility script or maybe add some extra functionality (eg batch system support or MPI).
If you are interested in contributing an entire new service to gLite, you have to speak to the
TCG.
In the following example you have produced a set of rpms which make jobs run faster. The rpms will be grouped together in a metapackage (
glite-TURBO
) with a yaim configuration and they need to be installed on the Worker Node.
How this is used
The ultimate aim is that a sysadmin would install and configure their WN like this
# yum install glite-WN glite-TURBO
# yaim -c -s /root/siteinfo/site-info.def -t WN -t TURBO
The Checklist
Approval
Please get approval in principle before starting any work. This page is describing necessary conditions for release, but these are not sufficient. The project has to want your stuff.
Version Control
Your source must be under version control. By default this would be the
JRA1 CVS
. Contact SA3 for access.
Licensing
The software must be appropriately licenced to allow us to distribute it. The standard gLite licence is
Apache-2
.
Build and packaging
The gLite release process is based around rpms produced by the
ETICS build system. It is highly desired that all components are built with
ETICS
. To make the process easier, SA3 will 'ETICSise' your stuff on the understanding that you then take over maintenance. Before we can do this, we need at least a Makefile with an
rpm
target.
Dependencies
Your rpms must not require any dependencies not already available within the target deployment platform (currently SL4 + jpackage 1.7 + DAG).
Configuration
Configuration should be done by yaim. Please see the
Yaim Developer Guide for instructions on producing your own yaim component. You will need to choose a 'configuration target' for your stuff, in this case
glite-TURBO
. The yaim module will be called
glite-yaim-turbo
.
Meta-packages
You will need to speak to the SA3 gLite release team about setting up appropriate meta-packages. This should correspond in name to the configuration target you have chosen within yaim, in this case
glite-TURBO
. Any dependencies you have should be specified in your rpms, not in the meta-package.
Acceptance criteria and documentation
The formally described release process -
MSA3.2
- contains certain acceptance criteria, frequently based around sufficient documentation. These are not all relevant in the case of a small extra utility, but please be aware of the larger context of requiring adequate documentation.
Release process
The final stage is to submit a
patch
, including details of your rpms, the yaim configuration module and the meta-packages. There is a link at the top of the patch submission page with instructions on how to complete the form.
All clear?
Presumably not. For the rest, contact
Oliver Keeble
--
OliverKeeble - 11 Oct 2007