<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head><title>AFPL Ghostscript maintenance procedures</title><!-- $Id: Maintain.htm,v 1.50 2005/10/20 19:46:23 ray Exp $ --><link rel="stylesheet" type="text/css" href="gs.css" title="Ghostscript Style"></head> <body><!-- [1.0 begin visible header] ============================================ --> <!-- [1.1 begin headline] ================================================== --> <h1>AFPL Ghostscript maintenance procedures</h1> <!-- [1.1 end headline] ==================================================== --> <!-- [1.2 begin table of contents] ========================================= --> <h2>Table of contents</h2> <blockquote><ul><li><a href="#Introduction">Introduction</a><li><a href="#Problem_reporting">Problem reporting</a><ul><li><a href="#Uploading_test_data">Uploading test data</a></ul><li><a href="#CVS">Rules for CVS commits</a><li><a href="#Adding_or_removing_files">Adding or Removing Files</a></ul></blockquote> <!-- [1.2 end table of contents] =========================================== --> <!-- [1.3 begin hint] ====================================================== --> <p>For other information, see the <a href="Readme.htm">Ghostscriptoverview</a> and the instructions on how to <a href="Make.htm">buildGhostscript</a>. <!-- [1.3 end hint] ======================================================== --> <hr> <!-- [1.0 end visible header] ============================================== --> <!-- [2.0 begin contents] ================================================== --> <h2><a name="Introduction"></a>Introduction</h2> <p>This document describes various maintenance procedures associated with AFPLGhostscript.  It is only meant for developers actively working on AFPLGhostscript; some parts of it are only relevant to developers who have commit access to the source repository. <hr> <h2><a name="Problem_reporting"></a>Problem reporting</h2> <h3><a name="#Uploading_test_data"></a>Uploading test data</h3> <p>If a test file can't be attached to the report in the public bug tracking system, put it in <tt>casper:/home/support/<bug number>/</tt>.This is a good place to collect test files of all kinds. <hr> <h2><a name="CVS"></a>Rules for CVS Commits</h2> <p>The primary repository for Ghostscript code is<a href="http://cvs.ghostscript.com" class="offsite">cvs.ghostscript.com</a>This section describes a few rules intended to make life easierfor people working with this code base. <p>At any given time, there are usually two active branches: a stablebranch and a development branch. The development branch is HEAD, whichis the default when doing a checkout without a -r flag. The stable branch is tagged after the previous major release. For example:GS_8_0x, GS_7_0x, GS_6_5. <p>A concise and useful document for working with CVS branches is JeffSemke's <a href="http://www.psc.edu/~semke/cvs_branches.html"class="offsite">CVSBranch and Tag Primer</a>. Asomewhat more detailed explanation is the <ahref="http://www.loria.fr/~molli/cvs/doc/cvs_5.html"class="offsite">Branching andmerging</a> section from the CVS documentation by Pascal Molli. <p>For new development commits, you can basically ignore thebranches. Just commit to the HEAD branch. For bug fixes for the stablebranch, it is your responsibility to commit to both the stable branchand, if appropriate, HEAD. <p>When modifying a number of files for a single issue, please group themtogether as a single commit. For two separate sets of changes dealingwith two different issues, there should be two commits. <p>You should strive not to introduce any new bugs with yourcommit. Always make sure the code compiles before committing. Test thechanges with several files, including the problem file in the case ofa bug fix, and other files that may have been affected by thechanges. <p>Always supply a descriptive log message for your commits. These logmessages are used to automatically generate the <ahref="News.htm">News.htm</a> file and History changelogs, and are alsocrucial for navigating the change history. Please try tokeep the style of the descriptions similar to those in the currentHistory#.htm files. <p>Log messages beginning with 'Fix' are treated specially. Such messages areput under the "Fixes problems" heading when the History files aregenerated. Additionally, if the first four characters are 'Fix:' this is removed(i.e., "Fix: The xyz" becomes "The xyz", but "Fixes xyz" is copied unchanged). This feature is intended for explicit bugfixes and should be avoided for enhancements or commits with long explanations. <p>Information about who changed what, when, and why is maintained in theCVS logs. In general, a file should be a clean representation of thecurrent version rather than a history trail of how it gotthere. Keeping old code around for reference is usually not necessary,as it is stored in the CVS diffs. When necessary, use #if / #endif, ordescriptive conditionals such as #ifdef OLD_CMAP_TABLES. Do notcomment out old code. (A very few files that are distributed separatefrom Ghostscript have a change log at the beginning, which should bemaintained: currently, only ansiknr.c and md5.[ch].) <p>Additionally, if your patch removes a feature, changes an interface orotherwise creates an incompatibility with the last release, youmust add an entry to the "Incompatible changes" section of <tt>News.htm</tt>as this information can only be generated manually.This admonition applies to api changes that mightaffect other developers as well as user issues like switch behavior.Upon release, the accumulated incompatible changes will be moved to the relevant History file, and the News collection in cvs will be wiped clean for the next version. <p>All patches should be reviewed before being committed. Please email yourpatch to <ahref="mailto:gs-code-review@ghostscript.com">gs-code-review@ghostscript.com</a>.Make sure to include your commit comment and any other informationthat would be helpful for the review. Also, please identify whichbranches the patch is intended for. The code review list is alsoa good place to put extensive documentation on changes (motivation andassociated reasoning for example) that are too verbose for the cvschangelog. <p>If you are not an employee or consultant of Artifex or artofcode, thenwe need a copyright assignment form so we can incorporate yourchanges. Please email Raph Levien &lt;<ahref="mailto:raph@artofcode.com">raph@artofcode.com</a>&gt; andinclude your snailmail address for a hardcopy assignment form. <h2><a name="Adding_or_removing_files"></a>Adding or removing files</h2> <p>When adding or removing files, don't forget to invoke <b><tt>cvsadd</tt></b> or <b><tt>cvs rm</tt></b>. <p>When adding files, update the file roadmap in<b><tt>doc/Develop.htm</tt></b>. <p>When adding or removing files other than .c or .h: If the files will beused at runtime, check the install list in <b><tt>unixinst.mak</tt></b>. <p>When adding .c files, update the relevant <b><tt>.mak</tt></b> file(usually <b><tt>devs.mak</tt></b>, <b><tt>int.mak</tt></b>, or<b><tt>lib.mak</tt></b>). <p>When adding new documentation, add a link to <tt>doc/Readme.htm</tt> anda short blurb describing the contents of the file. <p>When adding or changing fonts, update <b><tt>lib/Fontmap.GS</tt></b>,<b><tt>fonts.mak</tt></b>, and possibly the compiled fonts in<b><tt>gs.mak</tt></b> and the examples in<b><tt>doc/Fonts.htm</tt></b>. <p>When adding .ps files, update <b><tt>doc/Psfiles.htm</tt></b>. <p>Likewise, you will want to delete any references for a file youremove from Ghostscript. <!-- [2.0 end contents] ==================================================== --> <!-- [3.0 begin visible trailer] =========================================== --><hr> <p><small>Copyright &copy; 2000-2002 artofcode LLC.All rights reserved.</small> <p>This software is provided AS-IS with no warranty, either express orimplied. This software is distributed under license and may not be copied,modified or distributed except as expressly authorized under the termsof the license contained in the file LICENSE in this distribution. For more information about licensing, please refer tohttp://www.ghostscript.com/licensing/. For information oncommercial licensing, go to http://www.artifex.com/licensing/ orcontact Artifex Software, Inc., 101 Lucas Valley Road #110,San Rafael, CA  94903, U.S.A., +1(415)492-9861. <p><small>Ghostscript version 8.53, 20 October 2005 <!-- [3.0 end visible trailer] ============================================= --> </body></html>