By: Privoxy Developers
-$Id: developer-manual.sgml,v 1.15 2002/03/30 22:29:47 swa Exp $
+$Id: developer-manual.sgml,v 1.35 2002/04/17 15:16:15 oes Exp $
The developer manual gives the users information on how to help the developer
team. It provides guidance on coding, testing, documentation and other issues.
-Privoxy is a web proxy with advanced filtering capabilities for protecting
-privacy, filtering web page content, managing cookies, controlling access, and
-removing ads, banners, pop-ups and other obnoxious Internet junk. Privoxy has a
-very flexible configuration and can be customized to suit individual needs and
-tastes. Privoxy has application for both stand-alone systems and multi-user
-networks.
-
-Privoxy is based on the code of the Internet Junkbuster. Junkbuster was
-originally written by JunkBusters Corporation, and was released as free
-open-source software under the GNU GPL. Stefan Waldherr made many improvements,
-and started the SourceForge project to continue development. Other developers
-have since joined Stefan.
-
-You can find the latest version of the user manual at http://www.privoxy.org/
-developer-manual/. Please see the Contact section in the user-manual if you
-want to contact the developers.
+You can find the latest version of the this manual at http://www.privoxy.org/
+developer-manual/. Please see the Contact section on how to contact the
+developers.
-------------------------------------------------------------------------------
Table of Contents
+
1. Introduction
-2. Quickstart to Privoxy Development
-3. Documentation Guidelines
-4. Coding Guidelines
+3. Quickstart to Privoxy Development
+4. The CVS Repository
+
+ 4.1. Access to CVS
+ 4.2. CVS Commit Guideline
+ 4.3. Discussing Changes First
+
+5. Documentation Guidelines
+
+ 5.1. Quickstart to Docbook and SGML
+ 5.2. Privoxy Documentation Style
+ 5.3. Privoxy Custom Entities
+
+6. Coding Guidelines
- 4.1. Introduction
- 4.2. Using Comments
+ 6.1. Introduction
+ 6.2. Using Comments
- 4.2.1. Comment, Comment, Comment
- 4.2.2. Use blocks for comments
- 4.2.3. Keep Comments on their own line
- 4.2.4. Comment each logical step
- 4.2.5. Comment All Functions Thoroughly
- 4.2.6. Comment at the end of braces if the content is more than one
+ 6.2.1. Comment, Comment, Comment
+ 6.2.2. Use blocks for comments
+ 6.2.3. Keep Comments on their own line
+ 6.2.4. Comment each logical step
+ 6.2.5. Comment All Functions Thoroughly
+ 6.2.6. Comment at the end of braces if the content is more than one
screen length
- 4.3. Naming Conventions
+ 6.3. Naming Conventions
- 4.3.1. Variable Names
- 4.3.2. Function Names
- 4.3.3. Header file prototypes
- 4.3.4. Enumerations, and #defines
- 4.3.5. Constants
+ 6.3.1. Variable Names
+ 6.3.2. Function Names
+ 6.3.3. Header file prototypes
+ 6.3.4. Enumerations, and #defines
+ 6.3.5. Constants
- 4.4. Using Space
+ 6.4. Using Space
- 4.4.1. Put braces on a line by themselves.
- 4.4.2. ALL control statements should have a block
- 4.4.3. Do not belabor/blow-up boolean expressions
- 4.4.4. Use white space freely because it is free
- 4.4.5. Don't use white space around structure operators
- 4.4.6. Make the last brace of a function stand out
- 4.4.7. Use 3 character indentions
+ 6.4.1. Put braces on a line by themselves.
+ 6.4.2. ALL control statements should have a block
+ 6.4.3. Do not belabor/blow-up boolean expressions
+ 6.4.4. Use white space freely because it is free
+ 6.4.5. Don't use white space around structure operators
+ 6.4.6. Make the last brace of a function stand out
+ 6.4.7. Use 3 character indentions
- 4.5. Initializing
+ 6.5. Initializing
- 4.5.1. Initialize all variables
+ 6.5.1. Initialize all variables
- 4.6. Functions
+ 6.6. Functions
- 4.6.1. Name functions that return a boolean as a question.
- 4.6.2. Always specify a return type for a function.
- 4.6.3. Minimize function calls when iterating by using variables
- 4.6.4. Pass and Return by Const Reference
- 4.6.5. Pass and Return by Value
- 4.6.6. Names of include files
- 4.6.7. Provide multiple inclusion protection
- 4.6.8. Use `extern "C"` when appropriate
- 4.6.9. Where Possible, Use Forward Struct Declaration Instead of
+ 6.6.1. Name functions that return a boolean as a question.
+ 6.6.2. Always specify a return type for a function.
+ 6.6.3. Minimize function calls when iterating by using variables
+ 6.6.4. Pass and Return by Const Reference
+ 6.6.5. Pass and Return by Value
+ 6.6.6. Names of include files
+ 6.6.7. Provide multiple inclusion protection
+ 6.6.8. Use `extern "C"` when appropriate
+ 6.6.9. Where Possible, Use Forward Struct Declaration Instead of
Includes
- 4.7. General Coding Practices
+ 6.7. General Coding Practices
- 4.7.1. Turn on warnings
- 4.7.2. Provide a default case for all switch statements
- 4.7.3. Try to avoid falling through cases in a switch statement.
- 4.7.4. Use 'long' or 'short' Instead of 'int'
- 4.7.5. Don't mix size_t and other types
- 4.7.6. Declare each variable and struct on its own line.
- 4.7.7. Use malloc/zalloc sparingly
- 4.7.8. The Programmer Who Uses 'malloc' is Responsible for Ensuring
+ 6.7.1. Turn on warnings
+ 6.7.2. Provide a default case for all switch statements
+ 6.7.3. Try to avoid falling through cases in a switch statement.
+ 6.7.4. Use 'long' or 'short' Instead of 'int'
+ 6.7.5. Don't mix size_t and other types
+ 6.7.6. Declare each variable and struct on its own line.
+ 6.7.7. Use malloc/zalloc sparingly
+ 6.7.8. The Programmer Who Uses 'malloc' is Responsible for Ensuring
'free'
- 4.7.9. Add loaders to the `file_list' structure and in order
- 4.7.10. "Uncertain" new code and/or changes to exitinst code, use FIXME
+ 6.7.9. Add loaders to the `file_list' structure and in order
+ 6.7.10. "Uncertain" new code and/or changes to existing code, use FIXME
- 4.8. Addendum: Template for files and function comment blocks:
+ 6.8. Addendum: Template for files and function comment blocks:
-5. Version Control Guidelines
-6. Testing Guidelines
+7. Testing Guidelines
- 6.1. Testplan for releases
- 6.2. Test reports
+ 7.1. Testplan for releases
+ 7.2. Test reports
-7. Releasing a new version
+8. Releasing a New Version
- 7.1. Update the webserver
- 7.2. SuSE or RedHat
- 7.3. OS/2
- 7.4. Solaris
- 7.5. Windows
- 7.6. Debian
- 7.7. Mac OSX
- 7.8. FreeBSD
- 7.9. Tarball
- 7.10. HP-UX 11
- 7.11. Amiga OS
- 7.12. AIX
+ 8.1. Before the Release
+ 8.2. Building and Releasing the Packages
+
+ 8.2.1. Source Tarball
+ 8.2.2. SuSE or Red Hat
+ 8.2.3. OS/2
+ 8.2.4. Solaris
+ 8.2.5. Windows
+ 8.2.6. Debian
+ 8.2.7. Mac OSX
+ 8.2.8. FreeBSD
+ 8.2.9. HP-UX 11
+ 8.2.10. Amiga OS
+ 8.2.11. AIX
+
+ 8.3. After the Release
+
+9. Update the Webserver
+10. Contacting the developers, Bug Reporting and Feature Requests
+11. Copyright and History
-8. Contact the developers
-9. Copyright and History
-10. See also
+ 11.1. Copyright
+ 11.2. History
+
+12. See also
+
+-------------------------------------------------------------------------------
1. Introduction
-------------------------------------------------------------------------------
-2. Quickstart to Privoxy Development
+3. Quickstart to Privoxy Development
You'll need an account on Sourceforge to support our development. Mail your ID
-to the list and wait until a project manager has added you. For the time beeing
-(read, this section is under construction), please note the following
-guidelines for changing stuff in the code. If it is
+to the list and wait until a project manager has added you.
+
+For the time being (read, this section is under construction), please refer to
+the extensive comments in the source code.
+
+-------------------------------------------------------------------------------
+
+4. The CVS Repository
+
+If you intend to help us with programming, documentation or packaging you will
+need write access to our holy grail, the CVS repository. Please read this
+chapter completely before accessing via CVS.
+
+-------------------------------------------------------------------------------
+
+4.1. Access to CVS
+
+The project's CVS repository is hosted on SourceForge. Please refer to the
+chapters 6 and 7 in SF's site documentation for the technical access details
+for your operating system. For historical reasons, the CVS server is called
+cvs.ijbswa.sourceforge.net, the repository is called ijbswa, and the source
+tree module is called current.
+
+-------------------------------------------------------------------------------
- 1. A bugfix / clean-up / cosmetic thing: shoot
+4.2. CVS Commit Guideline
+
+The source tree is the heart of every software project. Every effort must be
+made to ensure that it is readable, compilable and consistent at all times. We
+therefore ask anyone with CVS access to strictly adhere to the following
+guidelines:
+
+ * Never (read: never, ever) be tempted to commit that small change without
+ testing it thoroughly first. When we're close to a public release, ask a
+ fellow developer to review your changes.
+
+ * Your commit message should give a concise overview of what you changed (no
+ big details) and why you changed it Just check previous messages for good
+ examples.
+
+ * Don't use the same message on multiple files, unless it equally applies to
+ all those files.
+
+ * If your changes span multiple files, and the code won't recompile unless
+ all changes are commited (e.g. when changing the signature of a function),
+ then commit all files one after another, without long delays in beween. If
+ necessary, prepare the commit messages in advance.
+
+ * Before changing things on CVS, make sure that your changes are in line with
+ the team's general consensus on what should be done (see below).
- 2. A new feature that can be turned off: shoot
+-------------------------------------------------------------------------------
+
+4.3. Discussing Changes First
+
+We don't have a too formal policy on this, just use common sense. Hints: If it
+is..
+
+ 1. ..a bugfix / clean-up / cosmetic thing: shoot
+
+ 2. ..a new feature that can be turned off: shoot
- 3. A clear improvement w/o side effects on other parts of the code: shoot
+ 3. ..a clear improvement w/o side effects on other parts of the code: shoot
- 4. A matter of taste: ask the list
+ 4. ..a matter of taste: ask the list
- 5. A major redesign of some part of the code: ask the list
+ 5. ..a major redesign of some part of the code: ask the list
+Note that near a major public release, we get a bit more cautious - if unsure,
+it doesn't hurt to ask first. There is always the possibility to submit a patch
+to the patches tracker instead.
+
-------------------------------------------------------------------------------
-3. Documentation Guidelines
+5. Documentation Guidelines
-All formal documents are maintained in docbook SGML and located in the doc/
-source directory. You will need docbook and the docbook stylesheets (or
-comparable alternatives), and either jade or openjade installed in order to
-build docs from source. Currently there is user-manual, FAQ, and, of course
-this, the developer-manual in this format.
+All formal documents are maintained in Docbook SGML and located in the doc/
+source/* directory. You will need Docbook, the Docbook DTD's and the Docbook
+modular stylesheets (or comparable alternatives), and either jade or openjade
+(recommended) installed in order to build docs from source. Currently there is
+user-manual, FAQ, and, of course this, the developer-manual in this format. The
+README, AUTHORS privoxy.1 (man page) files are also now maintained as Docbook
+SGML. The finished files are all in the top-level source directory are
+generated files! Also, index.html, the Privoxy home page, is maintained as
+SGML. DO NOT edit these directly. Edit the SGML source, or contact someone
+involved in the documentation (at present Stefan and Hal).
+
+Other, less formal documents (e.g. LICENSE, INSTALL) are maintained as plain
+text files in the top-level source directory. At least for the time being.
Packagers are encouraged to include this documentation. For those without the
-ability to build the docs locally, text versions of each are kept in CVS. Or
-HTML versions can be downloaded from the www.privoxy.org website, which should
-be fairly current.
+ability to build the docs locally, text versions of each are kept in CVS. HTML
+versions are also now being kept in CVS under doc/webserver/*.
-Documents are built with the Makefile targets of make dok, or alternately make
-redhat-dok. If you have problems, try both. The build process uses the document
-SGML sources in doc/source to update all text files in doc/text and to update
-all HTML documents in doc/webserver.
+Formal documents are built with the Makefile targets of make dok, or
+alternately make redhat-dok. If you have problems, try both. The build process
+uses the document SGML sources in doc/source/*/* to update all text files in
+doc/text/ and to update all HTML documents in doc/webserver/.
Documentation writers should please make sure documents build successfully
-before committing to CVS.
+before committing to CVS, if possible.
How do you update the webserver (i.e. the pages on privoxy.org)?
2. Run make webserver which copies all files from doc/webserver to the
sourceforge webserver via scp.
+Finished docs should be occasionally submitted to CVS (doc/webserver/*/*.html)
+so that those without the ability to build them locally, have access to them if
+needed. This is especially important just prior to a new release! Please do
+this after the $VERSION and other release specific data in configure.in has
+been updated (this is done just prior to a new release).
+
+-------------------------------------------------------------------------------
+
+5.1. Quickstart to Docbook and SGML
+
+If you are not familiar with SGML, it is a markup language similar to HTML.
+Actually, not a mark up language per se, but a language used to define markup
+languages. In fact, HTML is an SGML application. Both will use "tags" to format
+text and other content. SGML tags can be much more varied, and flexible, but do
+much of the same kinds of things. The tags, or "elements", are definable in
+SGML. There is no set "standards". Since we are using Docbook, our tags are
+those that are defined by Docbook. Much of how the finish document is rendered
+is determined by the "stylesheets". The stylesheets determine how each tag gets
+translated to HTML, or other formats.
+
+Tags in Docbook SGML need to be always "closed". If not, you will likely
+generate errors. Example: <title>My Title</title>. They are also
+case-insensitive, but we strongly suggest using all lower case. This keeps
+compatibility with [Docbook] XML.
+
+Our documents use "sections" for the most part. Sections will be processed into
+HTML headers (e.g. h1 for sect1). The Docbook stylesheets will use these to
+also generate the Table of Contents for each doc. Our TOC's are set to a depth
+of three. Meaning sect1, sect2, and sect3 will have TOC entries, but sect4 will
+not. Each section requires a <title> element, and at least one <para>. There is
+a limit of five section levels in Docbook, but generally three should be
+sufficient for our purposes.
+
+Some common elements that you likely will use:
+
+, paragraph delimiter. Most text needs to be within paragraph elements (there
+are some exceptions).
+, the stylesheets make this italics.
+, files and directories.
+, command examples.
+, like
+, more or less.
+, list with bullets.
+, member of the above.
+, screen output, implies .
+, like HTML tag.
+, for, doh, quoting text.
+
+Look at any of the existing docs for examples of all these and more.
+
+You might also find "Writing Documentation Using DocBook - A Crash Course"
+useful.
+
-------------------------------------------------------------------------------
-4. Coding Guidelines
+5.2. Privoxy Documentation Style
+
+It will be easier if everyone follows a similar writing style. This just makes
+it easier to read what someone else has written if it is all done in a similar
+fashion.
-4.1. Introduction
+Here it is:
+
+ * All tags should be lower case.
+
+ * Tags delimiting a block of text (even small blocks) should be on their own
+ line. Like:
+
+ <para>
+ Some text goes here.
+ </para>
+
+
+ Tags marking individual words, or few words, should be in-line:
+
+ Just to <emphasis>emphasize</emphasis>, some text goes here.
+
+
+ * Tags should be nested and step indented for block text like: (except
+ in-line tags)
+
+ <para>
+ <itemizedlist>
+ <para>
+ <listitem>
+ Some text goes here in our list example.
+ </listitem>
+ </para>
+ </itemizedlist>
+ </para>
+
+
+ This makes it easier to find the text amongst the tags ;-)
+
+ * Use white space to separate logical divisions within a document, like
+ between sections. Running everything together consistently makes it harder
+ to read and work on.
+
+ * Do not hesitate to make comments. Comments can either use the <comment>
+ element, or the <!-- --> style comment familiar from HTML. (Note in Docbook
+ v4.x <comment> is replaced by <remark>.)
+
+ * We have an international audience. Refrain from slang, or English
+ idiosyncrasies (too many to list :). Humor also does not translate well
+ sometimes.
+
+ * Try to keep overall line lengths in source files to 80 characters or less
+ for obvious reasons. This is not always possible, with lengthy URLs for
+ instance.
+
+ * Our documents are available in differing formats. Right now, they are just
+ plain text, and HTML, but PDF, and others is always a future possibility.
+ Be careful with URLs (<ulink>), and avoid this mistake:
+
+ My favorite site is <ulink url="http://example.com">here</ulink>.
+
+ This will render as "My favorite site is here", which is not real helpful
+ in a text doc. Better like this:
+
+ My favorite site is <ulink url="http://example.com">example.com</ulink>.
+
+ * All documents should be spell checked occasionally. aspell can check SGML
+ with the -H option. (ispell I think too.)
+
+-------------------------------------------------------------------------------
+
+5.3. Privoxy Custom Entities
+
+Privoxy documentation is using a number of customized "entities" to facilitate
+documentation maintenance.
+
+We are using a set of "boilerplate" files with generic text, that is used by
+multiple docs. This way we can write something once, and use it repeatedly
+without having to re-write the same content over and over again. If editing
+such a file, keep in mind that it should be generic. That is the purpose; so it
+can be used in varying contexts without additional modifications.
+
+We are also using what Docbook calls "internal entities". These are like
+variables in programming. Well, sort of. For instance, we have the p-version
+entity that contains the current Privoxy version string. You are strongly
+encouraged to use these where possible. Some of these obviously require
+re-setting with each release (done by the Makefile). A sampling of custom
+entities are listed below. See any of the main docs for examples.
+
+ * Re- "boilerplate" text entities are defined like:
+
+ <!entity supported SYSTEM "supported.sgml">
+
+ In this example, the contents of the file, supported.sgml is available for
+ inclusion anywhere in the doc. To make this happen, just reference the now
+ defined entity: &supported; (starts with an ampersand and ends with a
+ semi-colon), and the contents will be dumped into the finished doc at that
+ point.
+
+ * Commonly used "internal entities":
+
+ p-version: the Privoxy version string, e.g. "2.9.14".
+ p-status: the project status, either "alpha", "beta", or "stable".
+ p-not-stable: use to conditionally include text in "not stable" releases
+ (e.g. "beta").
+ p-stable: just the opposite.
+ p-text: this doc is only generated as text.
+
+There are others in various places that are defined for a specific purpose.
+Read the source!
+
+-------------------------------------------------------------------------------
+
+6. Coding Guidelines
+
+6.1. Introduction
This set of standards is designed to make our lives easier. It is developed
with the simple goal of helping us keep the "new and improved Privoxy"
-------------------------------------------------------------------------------
-4.2. Using Comments
+6.2. Using Comments
-4.2.1. Comment, Comment, Comment
+6.2.1. Comment, Comment, Comment
Explanation:
-------------------------------------------------------------------------------
-4.2.2. Use blocks for comments
+6.2.2. Use blocks for comments
Explanation:
Exception:
-If you are trying to add a small logic comment and do not wish to "disrubt" the
+If you are trying to add a small logic comment and do not wish to "disrupt" the
flow of the code, feel free to use a 1 line comment which is NOT on the same
line as the code.
-------------------------------------------------------------------------------
-4.2.3. Keep Comments on their own line
+6.2.3. Keep Comments on their own line
Explanation:
-------------------------------------------------------------------------------
-4.2.4. Comment each logical step
+6.2.4. Comment each logical step
Explanation:
-------------------------------------------------------------------------------
-4.2.5. Comment All Functions Thoroughly
+6.2.5. Comment All Functions Thoroughly
Explanation:
-------------------------------------------------------------------------------
-4.2.6. Comment at the end of braces if the content is more than one screen
+6.2.6. Comment at the end of braces if the content is more than one screen
length
Explanation:
-------------------------------------------------------------------------------
-4.3. Naming Conventions
+6.3. Naming Conventions
-4.3.1. Variable Names
+6.3.1. Variable Names
Explanation:
-Use all lowercase, and seperate words via an underscore ('_'). Do not start an
+Use all lowercase, and separate words via an underscore ('_'). Do not start an
identifier with an underscore. (ANSI C reserves these for use by the compiler
and system headers.) Do not use identifiers which are reserved in ANSI C++.
(E.g. template, class, true, false, ...). This is in case we ever decide to
-------------------------------------------------------------------------------
-4.3.2. Function Names
+6.3.2. Function Names
Explanation:
-Use all lowercase, and seperate words via an underscore ('_'). Do not start an
+Use all lowercase, and separate words via an underscore ('_'). Do not start an
identifier with an underscore. (ANSI C reserves these for use by the compiler
and system headers.) Do not use identifiers which are reserved in ANSI C++.
(E.g. template, class, true, false, ...). This is in case we ever decide to
-------------------------------------------------------------------------------
-4.3.3. Header file prototypes
+6.3.3. Header file prototypes
Explanation:
-------------------------------------------------------------------------------
-4.3.4. Enumerations, and #defines
+6.3.4. Enumerations, and #defines
Explanation:
-------------------------------------------------------------------------------
-4.3.5. Constants
+6.3.5. Constants
Explanation:
-------------------------------------------------------------------------------
-4.4. Using Space
+6.4. Using Space
-4.4.1. Put braces on a line by themselves.
+6.4.1. Put braces on a line by themselves.
Explanation:
if ( this == that ) { ... }
Note: In the special case that the if-statement is inside a loop, and it is
-trivial, i.e. it tests for a condidtion that is obvious from the purpose of the
+trivial, i.e. it tests for a condition that is obvious from the purpose of the
block, one-liners as above may optically preserve the loop structure and make
it easier to read.
-Status: developer-discrection.
+Status: developer-discretion.
Example exception:
-------------------------------------------------------------------------------
-4.4.2. ALL control statements should have a block
+6.4.2. ALL control statements should have a block
Explanation:
-------------------------------------------------------------------------------
-4.4.3. Do not belabor/blow-up boolean expressions
+6.4.3. Do not belabor/blow-up boolean expressions
Example:
if ( condition ) { structure->flag = 1; } else { structure->flag = 0; }
-Note: The former is readable and consice. The later is wordy and inefficient.
+Note: The former is readable and concise. The later is wordy and inefficient.
Please assume that any developer new to the project has at least a "good"
knowledge of C/C++. (Hope I do not offend by that last comment ... 8-)
-------------------------------------------------------------------------------
-4.4.4. Use white space freely because it is free
+6.4.4. Use white space freely because it is free
Explanation:
-------------------------------------------------------------------------------
-4.4.5. Don't use white space around structure operators
+6.4.5. Don't use white space around structure operators
Explanation:
-------------------------------------------------------------------------------
-4.4.6. Make the last brace of a function stand out
+6.4.6. Make the last brace of a function stand out
Example:
int function1( ... ) { ...code... return( retCode ); } int function2( ... ) { }
-Note: Use 1 blank line before the closing brace and 2 lines afterwards. This
+Note: Use 1 blank line before the closing brace and 2 lines afterward. This
makes the end of function standout to the most casual viewer. Although function
-comments help seperate functions, this is still a good coding practice. In
+comments help separate functions, this is still a good coding practice. In
fact, I follow these rules when using blocks in "for", "while", "do" loops, and
long if {} statements too. After all whitespace is free!
-Status: developer-discrection on the number of blank lines. Enforced is the end
+Status: developer-discretion on the number of blank lines. Enforced is the end
of function comments.
-------------------------------------------------------------------------------
-4.4.7. Use 3 character indentions
+6.4.7. Use 3 character indentions
Explanation:
-------------------------------------------------------------------------------
-4.5. Initializing
+6.5. Initializing
-4.5.1. Initialize all variables
+6.5.1. Initialize all variables
Explanation:
to access memory address 00000000 and not 129FA012; or arrayPtr[20] causes a
SIGSEV vs. arrayPtr[0].
-Status: developer-discrection if and only if the variable is assigned a value
+Status: developer-discretion if and only if the variable is assigned a value
"shortly after" declaration.
-------------------------------------------------------------------------------
-4.6. Functions
+6.6. Functions
-4.6.1. Name functions that return a boolean as a question.
+6.6.1. Name functions that return a boolean as a question.
Explanation:
-------------------------------------------------------------------------------
-4.6.2. Always specify a return type for a function.
+6.6.2. Always specify a return type for a function.
Explanation:
-------------------------------------------------------------------------------
-4.6.3. Minimize function calls when iterating by using variables
+6.6.3. Minimize function calls when iterating by using variables
Explanation:
-------------------------------------------------------------------------------
-4.6.4. Pass and Return by Const Reference
+6.6.4. Pass and Return by Const Reference
Explanation:
-------------------------------------------------------------------------------
-4.6.5. Pass and Return by Value
+6.6.5. Pass and Return by Value
Explanation:
-------------------------------------------------------------------------------
-4.6.6. Names of include files
+6.6.6. Names of include files
Explanation:
Example:
-#include <iostream.h> /* This is not a local include */
+#include /* This is not a local include */
#include "config.h" /* This IS a local include */
Exception:
/* This is not a local include, but requires a path element. */
-#include <sys/fileName.h>
+#include
Note: Please! do not add "-I." to the Makefile without a _very_ good reason.
-This duplicates the #include "file.h" behaviour.
+This duplicates the #include "file.h" behavior.
-------------------------------------------------------------------------------
-4.6.7. Provide multiple inclusion protection
+6.6.7. Provide multiple inclusion protection
Explanation:
-------------------------------------------------------------------------------
-4.6.8. Use `extern "C"` when appropriate
+6.6.8. Use `extern "C"` when appropriate
Explanation:
-------------------------------------------------------------------------------
-4.6.9. Where Possible, Use Forward Struct Declaration Instead of Includes
+6.6.9. Where Possible, Use Forward Struct Declaration Instead of Includes
Explanation:
Note: If you declare "file_list xyz;" (without the pointer), then including the
proper header file is necessary. If you only want to prototype a pointer,
-however, the header file is unneccessary.
+however, the header file is unnecessary.
-Status: Use with discrection.
+Status: Use with discretion.
-------------------------------------------------------------------------------
-4.7. General Coding Practices
+6.7. General Coding Practices
-4.7.1. Turn on warnings
+6.7.1. Turn on warnings
Explanation
-------------------------------------------------------------------------------
-4.7.2. Provide a default case for all switch statements
+6.7.2. Provide a default case for all switch statements
Explanation:
default :
log_error( ... );
- ... anomly code goes here ...
+ ... anomaly code goes here ...
continue; / break; / exit( 1 ); / etc ...
} /* end switch( hash_string( cmd ) ) */
switch statement. This API call *should* be included in a default statement.
Another Note: This is not so much a readability issue as a robust programming
-issue. The "anomly code goes here" may be no more than a print to the STDERR
+issue. The "anomaly code goes here" may be no more than a print to the STDERR
stream (as in load_config). Or it may really be an ABEND condition.
Status: Programmer discretion is advised.
-------------------------------------------------------------------------------
-4.7.3. Try to avoid falling through cases in a switch statement.
+6.7.3. Try to avoid falling through cases in a switch statement.
Explanation:
-------------------------------------------------------------------------------
-4.7.4. Use 'long' or 'short' Instead of 'int'
+6.7.4. Use 'long' or 'short' Instead of 'int'
Explanation:
-------------------------------------------------------------------------------
-4.7.5. Don't mix size_t and other types
+6.7.5. Don't mix size_t and other types
Explanation:
-------------------------------------------------------------------------------
-4.7.6. Declare each variable and struct on its own line.
+6.7.6. Declare each variable and struct on its own line.
Explanation:
variables; feel free to declare them on 1 line. You should, although, provide a
good comment on their functions.
-Status: developer-discrection.
+Status: developer-discretion.
-------------------------------------------------------------------------------
-4.7.7. Use malloc/zalloc sparingly
+6.7.7. Use malloc/zalloc sparingly
Explanation:
-Create a local stuct (on the stack) if the variable will live and die within
+Create a local struct (on the stack) if the variable will live and die within
the context of one function call.
Only "malloc" a struct (on the heap) if the variable's life will extend beyond
Example:
If a function creates a struct and stores a pointer to it in a
-list, then it should definately be allocated via `malloc'.
+list, then it should definitely be allocated via `malloc'.
-------------------------------------------------------------------------------
-4.7.8. The Programmer Who Uses 'malloc' is Responsible for Ensuring 'free'
+6.7.8. The Programmer Who Uses 'malloc' is Responsible for Ensuring 'free'
Explanation:
programmer's code. You are also responsible for ensuring that deletion is
timely (i.e. not too soon, not too late). This is known as "low-coupling" and
is a "good thing (tm)". You may need to offer a free/unload/destuctor type
-function to accomodate this.
+function to accommodate this.
Example:
The developer cannot be expected to provide `free'ing functions for C run-time
library functions ... such as `strdup'.
-Status: developer-discrection. The "main" use of this standard is for
-allocating and freeing data structures (complex or nested).
+Status: developer-discretion. The "main" use of this standard is for allocating
+and freeing data structures (complex or nested).
-------------------------------------------------------------------------------
-4.7.9. Add loaders to the `file_list' structure and in order
+6.7.9. Add loaders to the `file_list' structure and in order
Explanation:
-------------------------------------------------------------------------------
-4.7.10. "Uncertain" new code and/or changes to exitinst code, use FIXME
+6.7.10. "Uncertain" new code and/or changes to existing code, use FIXME
Explanation:
If you have enough confidence in new code or confidence in your changes, but
-are not *quite* sure of the reprocussions, add this:
+are not *quite* sure of the repercussions, add this:
-/* FIXME: this code has a logic error on platform XYZ, * attempthing to fix */
-#ifdef PLATFORM ...changed code here... #endif
+/* FIXME: this code has a logic error on platform XYZ, * attempting to fix */ #
+ifdef PLATFORM ...changed code here... #endif
or:
/* FIXME: new code that *may* break something else... */ ...new code here...
Note: If you make it clear that this may or may not be a "good thing (tm)", it
-will be easier to identify and include in the project (or conversly exclude
+will be easier to identify and include in the project (or conversely exclude
from the project).
-------------------------------------------------------------------------------
-4.8. Addendum: Template for files and function comment blocks:
+6.8. Addendum: Template for files and function comment blocks:
Example for file comments:
-const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 1.15 2002/03/30 22:29:47 swa Exp $";
+const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 1.35 2002/04/17 15:16:15 oes Exp $";
/*********************************************************************
*
* File : $Source$
change the "Copyright" section to represent the rights you wish to maintain.
Note: The formfeed character that is present right after the comment flower box
-is handy for (X|GNU)Emacs users to skip the verbige and get to the heart of the
-code (via `forward-page' and `backward-page'). Please include it if you can.
+is handy for (X|GNU)Emacs users to skip the verbiage and get to the heart of
+the code (via `forward-page' and `backward-page'). Please include it if you
+can.
Example for file header comments:
#ifndef _FILENAME_H
#define _FILENAME_H
-#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 1.15 2002/03/30 22:29:47 swa Exp $"
+#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 1.35 2002/04/17 15:16:15 oes Exp $"
/*********************************************************************
*
* File : $Source$
-------------------------------------------------------------------------------
-5. Version Control Guidelines
-
-To be filled. note on cvs comments. don't comment what you did, comment why you
-did it.
-
--------------------------------------------------------------------------------
-
-6. Testing Guidelines
+7. Testing Guidelines
To be filled.
-------------------------------------------------------------------------------
-6.1. Testplan for releases
+7.1. Testplan for releases
Explain release numbers. major, minor. developer releases. etc.
-------------------------------------------------------------------------------
-6.2. Test reports
+7.2. Test reports
Please submit test reports only with the test form at sourceforge. Three simple
steps:
-------------------------------------------------------------------------------
-7. Releasing a new version
+8. Releasing a New Version
+
+When we release versions of Privoxy, our work leaves our cozy secret lab and
+has to work in the cold RealWorld[tm]. Once it is released, there is no way to
+call it back, so it is very important that great care is taken to ensure that
+everything runs fine, and not to introduce problems in the very last minute.
-To minimize trouble with distribution contents, webpage errors and the like, I
-(Stefan) strongly encourage you to follow this section if you prepare a new
-release of code or new pages on the webserver.
+So when releasing a new version, please adhere exactly to the procedure
+outlined in this chapter.
The following programs are required to follow this process: ncftpput (ncftp),
-scp (ssh), gmake (GNU's version of make), ???.
+scp, ssh (ssh), gmake (GNU's version of make), autoconf, cvs.
+
+In the following text, replace X, Y and Z with the actual version number (X =
+major, Y = minor, Z = point):
-------------------------------------------------------------------------------
-7.1. Update the webserver
+8.1. Before the Release
-All files must be group-readable and group-writable (or no one else will be
-able to change them). To update the webserver, create any pages locally in the
-doc/webserver directory (or create new directories under doc/webserver), then
-do
+The following must be done by one of the developers prior to each new release.
- make webserver
-
+ * Make sure that everybody who has worked on the code in the last couple of
+ days has had a chance to yell "no!" in case they have pending changes/fixes
+ in their pipelines.
+
+ * Increment the version number and increase or reset the RPM release number
+ in configure.in as appropriate.
+
+ * If the default actionsfile has changed since last release, bump up its
+ version info in this line:
+
+ {+add-header{X-Actions-File-Version: A.B} -filter -no-popups}
+
+
+ Then change the version info in doc/webserver/actions/index.php, line:
+ '$required_actions_file_version = "A.B";'
+
+ * If the HTML documentation is not in sync with the SGML sources you need to
+ regenerate it. (If in doubt, just do it.) See the Section "Updating the
+ webserver" in this manual for details.
+
+ * Commit all files that were changed in the above steps!
+
+ * Tag all files in CVS with the version number with "cvs tag v_X_Y_Z". Don't
+ use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.
+
+-------------------------------------------------------------------------------
-Note that make dok creates doc/webserver/user-manual, doc/webserver/
-developer-manual, doc/webserver/faq and doc/webserver/man-page automatically.
+8.2. Building and Releasing the Packages
-Verify on the webserver that the permissions are set correctly. Do NOT use any
-other means of transferring files to the webserver.
+Now the individual packages can be built and released. Note that for GPL
+reasons the first package to be released is always the source tarball.
+
+For all types of packages, including the source tarball, you must make sure
+that you build from clean sources by exporting the right version from CVS into
+an empty directory:.
+
+ mkdir dist # delete or choose different name if it already exists
+ cd dist
+ cvs -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa login
+ cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa export -r v_X_Y_Z current
+
+
+Do NOT change a single bit, including, but not limited to version information
+after export from CVS. This is to make sure that all release packages, and with
+them, all future bug reports, are based on exactly the same code.
+
+Please find additional instructions for the source tarball and the individual
+platform dependent binary packages below.
-------------------------------------------------------------------------------
-7.2. SuSE or RedHat
+8.2.1. Source Tarball
+
+First, make sure that you have freshly exported the right version into an empty
+directory. (See "Building and releasing packages" above). Then run:
+
+ cd current
+ autoheader && autoconf && ./configure
+
-Ensure that you have the latest code version. Hence run
+Then do:
- cvs update .
+ make tarball-dist
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Update the release number directly in the specific spec file
-(particularly, set the release number to 1 if you have increased the version
-number before). Run
+To upload the package to Sourceforge, simply issue
- autoheader && autoconf && ./configure
+ make tarball-upload
+
+
+Go to the displayed URL and release the file publicly on Sourceforge. For the
+change log field, use the relevant section of the ChangeLog file.
+
+-------------------------------------------------------------------------------
+
+8.2.2. SuSE or Red Hat
+
+First, make sure that you have freshly exported the right version into an empty
+directory. (See "Building and releasing packages" above). Then run:
+
+ cd current
+ autoheader && autoconf && ./configure
Then do
- make suse-dist or make redhat-dist
+ make suse-dist (or make redhat-dist)
To upload the package to Sourceforge, simply issue
- make suse-upload or make redhat-upload
+ make suse-upload (or make redhat-upload)
-Goto the displayed URL and release the file publically on Sourceforge.
+Go to the displayed URL and release the file publicly on Sourceforge. Use the
+release notes and çhange log from the source tarball package.
-------------------------------------------------------------------------------
-7.3. OS/2
+8.2.3. OS/2
+
+First, make sure that you have freshly exported the right version into an empty
+directory. (See "Building and releasing packages" above). Then get the OS/2
+Setup module:
+
+ cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co os2setup
+
+
+You will need a mix of development tools. The main compilation takes place with
+IBM Visual Age C++. Some ancillary work takes place with GNU tools, available
+from various sources like hobbes.nmsu.edu. Specificially, you will need
+autoheader, autoconf and sh tools. The packaging takes place with WarpIN,
+available from various sources, including its home page: xworkplace.
-Ensure that you have the latest code version. Hence run
+Change directory to the os2setup directory. Edit the os2build.cmd file to set
+the final executable filename. For example,
- cvs update .
+ installExeName='privoxyos2_setup_X.Y.Z.exe'
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
+Next, edit the IJB.wis file so the release number matches in the PACKAGEID
+section:
- autoheader && autoconf && ./configure
+ PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"
-Then do FIXME.
+You're now ready to build. Run:
--------------------------------------------------------------------------------
+ os2build
+
-7.4. Solaris
+You will find the WarpIN-installable executable in the ./files directory.
+Upload this anonymously to uploads.sourceforge.net/incoming, create a release
+for it, and you're done. Use the release notes and Change Log from the source
+tarball package.
-Login to Sourceforge's compilefarm via ssh
+-------------------------------------------------------------------------------
- ssh cf.sourceforge.net
-
+8.2.4. Solaris
-Choose the right operating system (not the Debian one). If you have downloaded
-Privoxy before,
+Login to Sourceforge's compilefarm via ssh:
- cd current && cvs update .
+ ssh cf.sourceforge.net
-If not, please checkout Privoxy via CVS first. Verify the version number in
-configure.in. If necessary, change the version number. Run
+Choose the right operating system (not the Debian one). When logged in, make
+sure that you have freshly exported the right version into an empty directory.
+(See "Building and releasing packages" above). Then run:
- autoheader && autoconf && ./configure
+ cd current
+ autoheader && autoconf && ./configure
Then run
- gmake solaris-dist
+ gmake solaris-dist
which creates a gzip'ed tar archive. Sadly, you cannot use make solaris-upload
on the Sourceforge machine (no ncftpput). You now have to manually upload the
-archive to Sourceforge's ftp server and release the file publically
+archive to Sourceforge's ftp server and release the file publicly. Use the
+release notes and Change Log from the source tarball package.
-------------------------------------------------------------------------------
-7.5. Windows
+8.2.5. Windows
-Ensure that you have the latest code version. Hence run
+You should ensure you have the latest version of Cygwin (from http://
+www.cygwin.com/). Run the following commands from within a Cygwin bash shell.
- cvs update .
-
+First, make sure that you have freshly exported the right version into an empty
+directory. (See "Building and releasing packages" above). Then get the Windows
+setup module:
+
+ cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co winsetup
+
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
+Then you can build the package. This is fully automated, and is controlled by
+winsetup/GNUmakefile. All you need to do is:
- autoheader && autoconf && ./configure
+ cd winsetup
+ make
-Then do FIXME.
+Now you can manually rename privoxy_setup.exe to privoxy_setup_X_Y_Z.exe, and
+upload it to SourceForge. When releasing the package on SourceForge, use the
+release notes and Change Log from the source tarball package.
-------------------------------------------------------------------------------
-7.6. Debian
+8.2.6. Debian
-Ensure that you have the latest code version. Hence run
+First, make sure that you have freshly exported the right version into an empty
+directory. (See "Building and releasing packages" above). Then, run:
- cvs update .
-
-
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
-
- autoheader && autoconf && ./configure
+ cd current
+ autoheader && autoconf && ./configure
Then do FIXME.
-------------------------------------------------------------------------------
-7.7. Mac OSX
+8.2.7. Mac OSX
-Login to Sourceforge's compilefarm via ssh
+First, make sure that you have freshly exported the right version into an empty
+directory. (See "Building and releasing packages" above). Then get the Mac OSX
+setup module:
- ssh cf.sourceforge.net
-
+ cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co osxsetup
+
-Choose the right operating system. If you have downloaded Privoxy before,
+Then run:
- cd current && cvs update .
+ cd osxsetup
+ build
-If not, please checkout Privoxy via CVS first. Verify the version number in
-configure.in. If necessary, change the version number. Run
+This will run autoheader, autoconf and configure as well as make. Finally, it
+will copy over the necessary files to the ./osxsetup/files directory for
+further processing by PackageMaker.
- autoheader && autoconf && ./configure
-
-
-Then run
+Bring up PackageMaker with the PrivoxyPackage.pmsp definition file, modify the
+package name to match the release, and hit the "Create package" button. If you
+specify ./Privoxy.pkg as the output package name, you can then create the
+distributable zip file with the command:
- make macosx-dist
+zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
-which creates a gzip'ed tar archive. Sadly, you cannot use make macosx-upload
-on the Sourceforge machine (no ncftpput). You now have to manually upload the
-archive to Sourceforge's ftp server and release the file publically
+You can then upload privoxyosx_setup_x.y.z.zip anonymously to
+uploads.sourceforge.net/incoming, create a release for it, and you're done. Use
+the release notes and Change Log from the source tarball package.
-------------------------------------------------------------------------------
-7.8. FreeBSD
+8.2.8. FreeBSD
-Change the version number of Privoxy in the configure.in file. Run
+Login to Sourceforge's compilefarm via ssh:
- autoheader && autoconf && ./configure
+ ssh cf.sourceforge.net
-Then ...
-
-Login to Sourceforge's compilefarm via ssh
+Choose the right operating system. When logged in, make sure that you have
+freshly exported the right version into an empty directory. (See "Building and
+releasing packages" above). Then run:
- ssh cf.sourceforge.net
+ cd current
+ autoheader && autoconf && ./configure
-Choose the right operating system. If you have downloaded Privoxy before,
+Then run:
- cd current && cvs update .
+ gmake freebsd-dist
-If not, please checkout Privoxy via CVS first. Verify the version number in
-configure.in. If necessary, change the version number. Run
+which creates a gzip'ed tar archive. Sadly, you cannot use make freebsd-upload
+on the Sourceforge machine (no ncftpput). You now have to manually upload the
+archive to Sourceforge's ftp server and release the file publicly. Use the
+release notes and Change Log from the source tarball package.
- autoheader && autoconf && ./configure
-
+-------------------------------------------------------------------------------
-Then run
+8.2.9. HP-UX 11
+
+First, make sure that you have freshly exported the right version into an empty
+directory. (See "Building and releasing packages" above). Then run:
- gmake freebsd-dist
+ cd current
+ autoheader && autoconf && ./configure
-which creates a gzip'ed tar archive. Sadly, you cannot use make freebsd-upload
-on the Sourceforge machine (no ncftpput). You now have to manually upload the
-archive to Sourceforge's ftp server and release the file publically
+Then do FIXME.
-------------------------------------------------------------------------------
-7.9. Tarball
+8.2.10. Amiga OS
-Ensure that you have the latest code version. Hence run
+First, make sure that you have freshly exported the right version into an empty
+directory. (See "Building and releasing packages" above). Then run:
- cvs update .
+ cd current
+ autoheader && autoconf && ./configure
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
+Then do FIXME.
+
+-------------------------------------------------------------------------------
- make clobber
- autoheader && autoconf && ./configure
+8.2.11. AIX
+
+Login to Sourceforge's compilefarm via ssh:
+
+ ssh cf.sourceforge.net
-Then do
+Choose the right operating system. When logged in, make sure that you have
+freshly exported the right version into an empty directory. (See "Building and
+releasing packages" above). Then run:
- make tarball-dist
+ cd current
+ autoheader && autoconf && ./configure
-To upload the package to Sourceforge, simply issue
+Then run:
- make tarball-upload
+ make aix-dist
-Goto the displayed URL and release the file publically on Sourceforge.
+which creates a gzip'ed tar archive. Sadly, you cannot use make aix-upload on
+the Sourceforge machine (no ncftpput). You now have to manually upload the
+archive to Sourceforge's ftp server and release the file publicly. Use the
+release notes and Change Log from the source tarball package.
-------------------------------------------------------------------------------
-7.10. HP-UX 11
+8.3. After the Release
-Ensure that you have the latest code version. Hence run
+When all (or: most of the) packages have been uploaded and made available, send
+an email to the announce mailing list, Subject: "Version X.Y.Z available for
+download". Be sure to include the download location, the release notes and the
+change log.
- cvs update .
-
+-------------------------------------------------------------------------------
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
+9. Update the Webserver
- autoheader && autoconf && ./configure
-
+When updating the webserver, please follow these steps to make sure that no
+broken links, incosistent contents or permission problems will occur:
-Then do FIXME.
+If you have changed anything in the documentation source SGML files, do:
--------------------------------------------------------------------------------
+ make dok # (or make redkat-dok if make dok doesn't work for you)
+
-7.11. Amiga OS
+That will generate doc/webserver/user-manual, doc/webserver/developer-manual,
+doc/webserver/faq and doc/webserver/index.html automatically.
-Ensure that you have the latest code version. Hence run
+If you changed the manual page source, generate doc/webserver/man-page/
+privoxy-man-page.html by running "make man". (This is a separate target due to
+dependencies on some obscure perl scripts. See comments in GNUmakefile.)
- cvs update .
-
+If you want to add new files to the webserver, create them locally in the doc/
+webserver/* directory (or create new directories under doc/webserver).
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
+Next, commit any changes from the above steps to CVS. All set? Then do
- autoheader && autoconf && ./configure
+ make webserver
-Then do FIXME.
+This will do the upload to the webserver (www.privoxy.org) and ensure all files
+and directories there are group writable.
+
+Please do NOT use any other means of transferring files to the webserver to
+avoid permission problems.
-------------------------------------------------------------------------------
-7.12. AIX
+10. Contacting the developers, Bug Reporting and Feature Requests
-Login to Sourceforge's compilefarm via ssh
+We value your feedback. However, to provide you with the best support, please
+note:
- ssh cf.sourceforge.net
-
+ * Use the Sourceforge Support Forum to get help:
+
+ http://sourceforge.net/tracker/?group_id=11118&atid=211118
+
+
+ * Submit bugs only through our Sourceforge Bug Forum:
+
+ http://sourceforge.net/tracker/?group_id=11118&atid=111118.
+
+
+ Make sure that the bug has not already been submitted. Please try to verify
+ that it is a Privoxy bug, and not a browser or site bug first. If you are
+ using your own custom configuration, please try the stock configs to see if
+ the problem is a configuration related bug. And if not using the latest
+ development snapshot, please try the latest one. Or even better, CVS
+ sources. Please be sure to include the Privoxy/Junkbuster version,
+ platform, browser, any pertinent log data, any other relevant details
+ (please be specific) and, if possible, some way to reproduce the bug.
+
+ * Submit feature requests only through our Sourceforge feature request forum:
+
+ http://sourceforge.net/tracker/?atid=361118&group_id=11118&func=browse.
+
+
+ * You can also send feedback on websites that Privoxy has problems with. Please bookmark
+ the following link: "Privoxy - Submit Filter Feedback"
+ . Once you surf to a page with problems, use the
+ bookmark to send us feedback. We will look into the issue as soon as possible.
+
+
+ * For any other issues, feel free to use the mailing lists:
+
+ http://sourceforge.net/mail/?group_id=11118.
+
+
+ Anyone interested in actively participating in development and related
+ discussions can also join the appropriate mailing list. Archives are
+ available, too.
+
+-------------------------------------------------------------------------------
-Choose the right operating system. If you have downloaded Privoxy before,
+11. Copyright and History
- cd current && cvs update .
-
+11.1. Copyright
-If not, please checkout Privoxy via CVS first. Verify the version number in
-configure.in. If necessary, change the version number. Run
+Privoxy is free software; you can redistribute it and/or modify it under the
+terms of the GNU General Public License as published by the Free Software
+Foundation; either version 2 of the License, or (at your option) any later
+version.
- autoheader && autoconf && ./configure
-
+This program is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
+PARTICULAR PURPOSE. See the GNU General Public License for more details, which
+is available from the Free Software Foundation, Inc, 59 Temple Place - Suite
+330, Boston, MA 02111-1307, USA.
-Then run
+You should have received a copy of the GNU General Public License along with
+this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+Place, Suite 330, Boston, MA 02111-1307 USA.
- make aix-dist
-
+-------------------------------------------------------------------------------
-which creates a gzip'ed tar archive. Sadly, you cannot use make aix-upload on
-the Sourceforge machine (no ncftpput). You now have to manually upload the
-archive to Sourceforge's ftp server and release the file publically
+11.2. History
+
+Privoxy is evolved, and derived from, the Internet Junkbuster, with many
+improvments and enhancements over the original.
+
+Junkbuster was originally written by Anonymous Coders and Junkbusters
+Corporation, and was released as free open-source software under the GNU GPL.
+Stefan Waldherr made many improvements, and started the SourceForge project
+Privoxy to rekindle development. There are now several active developers
+contributing. The last stable release of Junkbuster was v2.0.2, which has now
+grown whiskers ;-).
-------------------------------------------------------------------------------
-8. Contact the developers
+12. See also
-Please see the contact page in the user-manual for details.
+Other references and sites of interest to Privoxy users:
--------------------------------------------------------------------------------
+http://www.privoxy.org/, The Privoxy Home page.
-9. Copyright and History
+http://sourceforge.net/projects/ijbswa, the Project Page for Privoxy on
+Sourceforge.
-Please see the user-manual for information on Copyright and History.
+http://p.p/, access Privoxy from your browser. Alternately, http://
+config.privoxy.org may work in some situations where the first does not.
--------------------------------------------------------------------------------
+http://p.p/, and select "actions file feedback system" to submit "misses" to
+the developers.
+
+http://www.junkbusters.com/ht/en/cookies.html
+
+http://www.waldherr.org/junkbuster/
+
+http://privacy.net/analyze/
-10. See also
+http://www.squid-cache.org/
-Please see the user-manual for others references.
+