OSS Official Product Support Checklist:
What Does it Take to Build a Product to OSS Standards?

1. UPS Packaging.
   All products that OSS delivers (other than operating systems, patches, vendor-supplied compilers, etc.) will be provided in UPS packaging, suitable for distribution from the fnkits.fnal.gov repository. Additionally, OSS products should include:
   • README (or README.fnal) file in $PRODUCT_DIR describing what the product is, what it does, where it came from, any FNAL-specific modifications, etc.
   • Wherever possible, the product should be self-contained and relocatable.
   • Man pages should be provided, usually under $PRODUCT_DIR/ups/toman/man (unformatted) and/or $PRODUCT_DIR/ups/toman/catman (formatted).
   • Soon, we hope to have guidelines on how to handle products which require root privilege for installation.
   • Soon, we hope to have guidelines on how to handle products which cannot be relocatable.
   • Are there other ups summary statements that would be good here? Please let me know...

2. Product Documentation Repository.
   All products that OSS delivers should have documentation placed in the Product Documentation Repository under

        /afs/fnal.gov/files/docs/products/<product_name>/
   

   which maps to the URL

        http://www.fnal.gov/docs/products/<product_name>/
   

   • When a product is updated, update the documentation too!
   • An index.html file should be provided; it may be a link to (e.g.,) <product_name>.html.
   • Some products may require documentation for more than one release to be available; in this case, we recommend /afs/fnal.gov/files/docs/products/<product_name>/<version_number>.

3. Product/Document Database.
   All products that OSS delivers should be entered into the Product/Document Database. The Product Input Form asks for:
   • product name (as in fnkits -- the thing you "setup")
   • description
   • keywords to be used in a search
   • is it a child or member of a family (e.g., cmdbinutl is a member of the systools family)
   • platform type (in most cases, this will be UNIX)
   • support level (full+consulting, full, maintenance, internal, or minimal)
   • origin (in-house/locally-developed, HEPware, freeware/shareware, or commercial)
   • life cycle (new, active, deprecated or obsolete)
   • contact group
   • contact person
   • contact email
   • documentation location (this should always be http://www.fnal.gov/docs/products/<product_name> for OSS products)
   • documentation format
   • FermiTools URL (if applicable)
   • submitter email
   • comments

4. News Postings.
   When new versions are released, news should be posted into the appropriate newsgroups (typically, fnal.announce.products and/or fnal.announce.unix). Include:
   • Name, version, flavor(s) being released
   • What does this product do?
   • If being released as "test", when is it scheduled to go "current"? (Another news posting should be made when the product actually goes "current").
   • What is new in this release? What bugs are fixed? What problems exist? Why do people care about this release?
   • Where can additional documentation be found?