Release Process

Current release managers for current/

• Philip Brown
• James Lee

Process for submitting packages

1. The maintainer copies over the packages to bender.opencsw.org:/home/newpkgs
2. An email is written to gro.wscnepo.stsil|snoissimbusgkp#gro.wscnepo.stsil|snoissimbusgkp with the subject "newpkgs <pkg1>, <pkg2>, … and the full filenames of the packages in the body of the mail. Renaming of the catalog- or package names must be stated in the email.

Process for adding a new package to the catalog

This is performed by a release manager

1. Once a package is put in /home/newpkgs on www.opencsw.org by the maintainer, the release manager looks it over to see if there's any "gotchas" to it, and run checkpkg on it. The current status of the review process is documented in the file /home/newpkgs/00-README again on www.opencsw.org.
2. If everything looks good, then the script registerpkg is called to add it to a trivial mysql table. An area to mantis is added for it if there isntt one already. This script is sitting at /home/phil/oldhome/sbin/registerpkg on www.opencsw.org
3. A catalog update script is called and the catalog is signed
4. rsync to our master site

Package examination

These are typical things to examine in a newly built package:

• The list of files
  • Presence of odd paths
• Dependencies
  • Obsolete dependencies
  • Non-optimal dependencies
• Needed shared libraries

These packages usually need more attention:

• New packages
• Packages of new maintainers
• Renamed packages
• Packages which have not been updated in a very long time

Some packages require knowledge about specifics of certain technology or language (We could use language-specific release managers for these types of packages!):

• Perl
• Python
• Ruby

See also

• Automated release process