<HTML>
<HEAD>
<META NAME="DOCNUMBER" CONTENT="CUPS-CMP-1.1">
<META NAME="COPYRIGHT" CONTENT="Copyright 1997-2002, All Rights Reserved">
<META NAME="Author" CONTENT="Easy Software Products">
<TITLE>CUPS Configuration Management Plan</TITLE>
</HEAD>
<BODY>
<H1>Scope</H1>
<H2>Identification</H2>
This configuration management plan document provides the guidelines for
development and maintenance of the Common UNIX Printing System ("CUPS")
Version 1.1 software.
<EMBED SRC="system-overview.shtml">
<H2>Document Overview</H2>
This configuration management document is organized into the following
sections:
<UL>
<LI>1 - Scope</LI>
<LI>2 - References</LI>
<LI>3 - File Management</LI>
<LI>4 - Trouble Report Processing</LI>
<LI>5 - Software Releases</LI>
<LI>A - Glossary</LI>
<LI>B - Coding Requirements</LI>
</UL>
<EMBED SRC="references.shtml">
<H1>File Management</H1>
<H2>Directory Structure</H2>
Each source file shall be placed a sub-directory corresponding to the software
sub-system it belongs to ("scheduler", "cups", etc.) To remain compatible
with older UNIX filesystems, directory names shall not exceed 16 characters
in length.
<H2>Source Files</H2>
Source files shall be documented and formatted as described in Appendix
B, Coding Requirements.
<H2>Configuration Management</H2>
Source files shall be placed under the control of the Concurrent Versions
System ("CVS") software. Source files shall be "checked in" with each change
so that modifications can be tracked.
<P>Documentation on the CVS software is included with the whitepaper, "CVS
II: Parallelizing Software Development".
<H1>Trouble Report Processing</H1>
A Software Trouble Report ("STR") shall be submitted every time a user
or vendor experiences a problem with the CUPS software. Trouble reports
are maintained in a database with one of the following states:
<OL>
<LI>STR is closed with complete resolution</LI>
<LI>STR is closed without resolution</LI>
<LI>STR is active</LI>
<LI>STR is pending (new STR or additional information available)</LI>
</OL>
Trouble reports shall be processed using the following steps.
<H2>Classification</H2>
When a trouble report is received it must be classified at one of the following
levels:
<OL>
<LI>Request for enhancement</LI>
<LI>Documentation error</LI>
<LI>Unable to print a file</LI>
<LI>Unable to print to a printer</LI>
<LI>Unable to print at all</LI>
</OL>
The scope of the problem should also be determined as:
<OL>
<LI>Specific to a machine</LI>
<LI>Specific to an operating system</LI>
<LI>Applies to all machines and operating systems</LI>
</OL>
<H2>Identification</H2>
Once the level and scope of the trouble report is determined the software
sub-system(s) involved with the problem are determined. This may involve
additional communication with the user or vendor to isolate the problem
to a specific cause.
<P>When the sub-system(s) involved have been identified, an engineer will
then determine the change(s) needed and estimate the time required for
the change(s).
<H2>Correction</H2>
Corrections are scheduled based upon the severity and complexity of the
problem. Once all changes have been made, documented, and tested successfully
a new software release snapshot is generated. Additional tests are added
as necessary for proper testing of the changes.
<H2>Notification</H2>
The user or vendor is notified when the fix is available or if the problem
was caused by user error.
<H1>Software Releases</H1>
<H2>Version Numbering</H2>
CUPS uses a three-part version number separated by periods to represent
the major, minor, and patch release numbers:
<UL>
<PRE>
major.minor.patch
1.1.0
</PRE>
</UL>
Beta-test releases are indentified by appending the letter B followed by
the build number:
<UL>
<PRE>
major.minor.patchbbuild
1.1.0b1
</PRE>
</UL>
A CVS snapshot is generated for every beta and final release and uses
the version number preceded by the letter "v" and with the decimal
points replaced by underscores:
<UL>
<PRE>
v1_0_0b1
v1_0_0
</PRE>
</UL>
Each change that corrects a fault in a software sub-system increments the
patch release number. If a change affects the software design of CUPS then
the minor release number will be incremented and the patch release number
reset to 0. If CUPS is completely redesigned the major release number will
be incremented and the minor and patch release numbers reset to 0:
<UL>
<PRE>
1.1.0b1 First beta release
1.1.0b2 Second beta release
1.1.0 First production release
1.1.1b1 First beta of 1.1.1
1.1.1 Production release of 1.1.1
1.1.1b1 First beta of 1.1.1
1.1.1 Production release of 1.1.1
2.0.0b1 First beta of 2.0.0
2.0.0 Production release of 2.0.0
</PRE>
</UL>
<H2>Generation</H2>
Software releases shall be generated for each successfully completed software
trouble report. All object and executable files shall be deleted prior
to performing a full build to ensure that source files are recompiled.
<H2>Testing</H2>
Software testing shall be conducted according to the CUPS Software Test
Plan, CUPS-STP-1.1. Failed tests cause STRs to be generated to correct
the problems found.
<H2>Release</H2>
When testing has been completed successfully a new distribution image is
created from the current CVS code "snapshot". No production release shall
contain software that has not passed the appropriate software tests.
<EMBED SRC="glossary.shtml">
<H1>Coding Requirements</H1>
These coding requirements provide detailed information on source file
formatting and documentation content. These guidelines shall be applied
to all C and C++ source files provided with CUPS.
<H2>Source Files</H2>
<H3>Naming</H3>
All source files names shall be 16 characters or less in length to
ensure compatibility with older UNIX filesystems. Source files
containing functions shall have an extension of ".c" for ANSI C and
".cxx" for C++ source files. All other "include" files shall have an
extension of ".h".
<H3>Documentation</H3>
The top of each source file shall contain a header giving the name of the
file, the purpose or nature of the source file, the copyright and licensing
notice, and the functions contained in the file. The file name and revision
information is provided by the CVS "$Id$" tag:
<UL>
<PRE>
/*
* "$Id$"
*
* Description of file contents.
*
* Copyright 1997-2002 by Easy Software Products, all rights
* reserved.
*
* These coded instructions, statements, and computer programs are
* the property of Easy Software Products and are protected by
* Federal copyright law. Distribution and use rights are outlined
* in the file "LICENSE.txt" which should have been included with
* this file. If this file is missing or damaged please contact
* Easy Software Products at:
*
* Attn: CUPS Licensing Information
* Easy Software Products
* 44141 Airport View Drive, Suite 204
* Hollywood, Maryland 20636-3111 USA
*
* Voice: (301) 373-9600
* EMail: cups-info@cups.org
* WWW: http://www.cups.org
*
* Contents:
*
* function1() - Description 1.
* function2() - Description 2.
* function3() - Description 3.
*/
</PRE>
</UL>
The bottom of each source file shall contain a trailer giving the name
of the file using the CVS "$Id$" tag. The primary purpose of this is to
mark the end of a source file; if the trailer is missing it is possible
that code has been lost near the end of the file:
<UL>
<PRE>
/*
* End of "$Id$".
*/
</PRE>
</UL>
<H2>Functions</H2>
<H3>Naming</H3>
Functions with a global scope shall be capitalized ("DoThis", "DoThat",
"DoSomethingElse", etc.) The only exception to this rule shall be the
CUPS interface library functions which may begin with a prefix word in
lowercase ("cupsDoThis", "cupsDoThat", etc.)
<P>Functions with a local scope shall be declared "static" and be lowercase
with underscores between words ("do_this", "do_that", "do_something_else",
etc.)
<H3>Documentation</H3>
Each function shall begin with a comment header describing what the function
does, the possible input limits (if any), and the possible output values
(if any), and any special information needed:
<UL>
<PRE>
/*
* 'do_this()' - Compute y = this(x).
*
* Notes: none.
*/
static float /* O - Inverse power value, 0.0 <= y <= 1.1 */
do_this(float x) /* I - Power value (0.0 <= x <= 1.1) */
{
...
return (y);
}
</PRE>
</UL>
<H2>Methods</H2>
<H3>Naming</H3>
Methods shall be in lowercase with underscores between words ("do_this",
"do_that", "do_something_else", etc.)
<H3>Documentation</H3>
Each method shall begin with a comment header describing what the method
does, the possible input limits (if any), and the possible output values
(if any), and any special information needed:
<UL>
<PRE>
/*
* 'class::do_this()' - Compute y = this(x).
*
* Notes: none.
*/
float /* O - Inverse power value, 0.0 <= y <= 1.0 */
class::do_this(float x) /* I - Power value (0.0 <= x <= 1.0) */
{
...
return (y);
}
</PRE>
</UL>
<H2>Variables</H2>
<H3>Naming</H3>
Variables with a global scope shall be capitalized ("ThisVariable",
"ThatVariable", "ThisStateVariable", etc.) The only exception to this
rule shall be the CUPS interface library global variables which must
begin with the prefix "cups" ("cupsThisVariable", "cupsThatVariable",
etc.) Global variables shall be replaced by function arguments whenever
possible.
<P>Variables with a local scope shall be lowercase with underscores between
words ("this_variable", "that_variable", etc.) Any local variables shared
by functions within a source file shall be declared "static".
<H3>Documentation</H3>
Each variable shall be declared on a separate line and shall be immediately
followed by a comment block describing the variable:
<UL><PRE>
int this_variable; /* The current state of this */
int that_variable; /* The current state of that */
</PRE></UL>
<H2>Types</H2>
<H3>Naming</H3>
All type names shall be lowercase with underscores between words and
"_t" appended to the end of the name ("this_type_t", "that_type_t",
etc.)
<H3>Documentation</H3>
Each type shall have a comment block immediately before the typedef:
<UL>
<PRE>
/*
* This type is for CUPS foobar options.
*/
typedef int cups_this_type_t;
</PRE>
</UL>
<H2>Structures</H2>
<H3>Naming</H3>
All structure names shall be lowercase with underscores between words and
"_str" appended to the end of the name ("this_struct_str", "that_struct_str",
etc.)
<H3>Documentation</H3>
Each structure shall have a comment block immediately before the struct
and each member shall be documented in accordance with the variable naming
policy above:
<UL>
<PRE>
/*
* This structure is for CUPS foobar options.
*/
struct cups_this_struct_str
{
int this_member; /* Current state for this */
int that_member; /* Current state for that */
};
</PRE>
</UL>
<H2>Classes</H2>
<H3>Naming</H3>
All class names shall be lowercase with underscores between words
("this_class", "that_class", etc.)
<H3>Documentation</H3>
Each class shall have a comment block immediately before the class
and each member shall be documented in accordance with the variable naming
policy above:
<UL>
<PRE>
/*
* This class is for CUPS foobar options.
*/
class cups_this_class
{
int this_member; /* Current state for this */
int that_member; /* Current state for that */
};
</PRE>
</UL>
<H2>Constants</H2>
<H3>Naming</H3>
All constant names shall be uppercase with underscored between words
("THIS_CONSTANT", "THAT_CONSTANT", etc.) Constants defined for the CUPS
interface library must begin with an uppercase prefix
("CUPS_THIS_CONSTANT", "CUPS_THAT_CONSTANT", etc.)
<P>Typed enumerations shall be used whenever possible to allow for type
checking by the compiler.
<H3>Documentation</H3>
Comment blocks shall immediately follow each constant:
<UL>
<PRE>
enum
{
CUPS_THIS_TRAY, /* This tray */
CUPS_THAT_TRAY /* That tray */
};
</PRE>
</UL>
<H2>Code</H2>
<H3>Documentation</H3>
All source code shall utilize block comments within functions to describe
the operations being performed by a group of statements:
<UL>
<PRE>
/*
* Clear the state array before we begin...
*/
for (i = 0; i < (sizeof(array) / sizeof(sizeof(array[0])); i ++)
array[i] = STATE_IDLE;
/*
* Wait for state changes...
*/
do
{
for (i = 0; i < (sizeof(array) / sizeof(sizeof(array[0])); i ++)
if (array[i] != STATE_IDLE)
break;
if (i == (sizeof(array) / sizeof(array[0])))
sleep(1);
} while (i == (sizeof(array) / sizeof(array[0])));
</PRE>
</UL>
<H3>Style</H3>
<H4 TYPE="a">Indentation</H4>
All code blocks enclosed by brackets shall begin with the opening brace
on a new line. The code then follows starting on a new line after the brace
and is indented 2 spaces. The closing brace is then placed on a new line
following the code at the original indentation:
<UL>
<PRE>
{
int i; /* Looping var */
/*
* Process foobar values from 0 to 999...
*/
for (i = 0; i < 1000; i ++)
{
do_this(i);
do_that(i);
}
}
</PRE>
</UL>
Single-line statements following "do", "else", "for", "if", and "while"
shall be indented 2 spaces as well. Blocks of code in a "switch" block
shall be indented 4 spaces after each "case" and "default" case:
<UL>
<PRE>
switch (array[i])
{
case STATE_IDLE :
do_this(i);
do_that(i);
break;
default :
do_nothing(i);
break;
}
</PRE>
</UL>
<H4>Spacing</H4>
A space shall follow each reserved word ("if", "while", etc.) Spaces shall
not be inserted between a function name and the arguments in parenthesis.
<H4>Return Values</H4>
Parenthesis shall surround values returned from a function using "return":
<UL>
<PRE>
return (STATE_IDLE);
</PRE>
</UL>
<H4>Loops</H4>
Whenever convenient loops should count downward to zero to improve program
performance:
<UL>
<PRE>
for (i = sizeof(array) / sizeof(array[0]) - 1; i >= 0; i --)
array[i] = STATE_IDLE;
</PRE>
</UL>
<H1 ALIGN=RIGHT>Software Trouble Report Form</H1>
<CENTER><TABLE WIDTH="80%">
<TR>
<TH ALIGN=RIGHT>Summary of Problem:</TH>
<TD ALIGN=LEFT>________________________________________</TD>
</TR>
<TR>
<TH ALIGN=RIGHT>Problem Severity:</TH>
<TD ALIGN=LEFT>__1=RFE
<BR>__2=Documentation-Error
<BR>__3=Unable-to-Print-a-File
<BR>__4=Unable-to-Print-to-a-Printer
<BR>__5=Unable-to-Print-at-All</TD>
</TR>
<TR>
<TH ALIGN=RIGHT>Problem Scope:</TH>
<TD ALIGN=LEFT>__1=Machine __2=Operating-System __3=All</TD>
</TR>
<TR>
<TH ALIGN=RIGHT VALIGN=TOP>Detailed Description of Problem:</TH>
<TD ALIGN=LEFT>________________________________________
<BR>________________________________________
<BR>________________________________________
<BR>________________________________________
<BR>________________________________________
<BR>________________________________________</TD>
</TR>
</TABLE></CENTER>
</BODY>
</HTML>