GT Project Guidelines
From Globus
Projects wishing to contribute products for inclusion in the Globus Toolkit should follow these guidelines:
Contents |
Code
- backward compatibility
- public interface stability
- cross-product interoperability
- licensing
- platform support
- repository branching and tagging
Documentation
Packages should have admin/user/developer guides as appropriate. There will need to be an admin/ configuration guide, a user's guide, and a developer's guide where appropriate. The ideal would be docbook that committed into the gt- manuals repo.
Packaging
1.) Directory structure
Packages shouldn't create new top-level subdirectories of $GLOBUS_LOCATION. Packages should place their different file types in the appropriate existing subdirectories. Crowded subdirectories like etc/ and share/ should get package-specific subdirectories. The filesystem guidelines for Globus are the following:
2.) Files
- Configuration files - $GL/etc/<your_package>/
- User-level binaries - $GL/bin/
- Admin-level binaries - $GL/sbin
- Internal binaries - $GL/libexec
- Libraries - $GL/lib
- Templates/misc - $GL/share/<your_package>/
- Headers - $GL/include
- Man pages - $GL/man/man<n>/
- Setup scripts - $GL/setup/<your_package>
- Tests - $GL/test/<your_package>
- Nothing goes to $GL/var or $GL/tmp except at runtime
- Creation of new subdirectories is not encouraged.
3.) Binaries
Packages should permit relocatable binary packaging. If any files in the package are installdir specific, those files should be created/modified by a postinstall setup script.
Testing
Packages should provide a test-running script that will let us test the package for correctness during nightly builds. Aside from the filesystem placement, the testing requirements are:
Create a script called $GL/test/<your_package>/TESTS.pl. Running that script should run your tests. It should return 0 on success, non-zero on failuire. All of the information required for debugging should show up on stdout/stderr. For instance, some junit tests try to output nice HTML logfiles. That's fine, but we don't automatically fetch things like that in our nightly build harness
User support
Package owners must agree to support their software in the current release and one stable release prior. In the stable release series, published APIs will not change, and wire protocols will not change. There should be a bugzilla category to file bugs against. Bugs should be responded to in a timely fashion. There should be a user mailing list to handle email support requests. Published APIs must continue to work in the stable series. Additions to the public API should be exclusively additive.
