Privoxy Developer Manual
-By: Privoxy Developers
+Copyright © 2001, 2002 by Privoxy Developers
-$Id: developer-manual.sgml,v 1.15 2002/03/30 22:29:47 swa Exp $
+$Id: developer-manual.sgml,v 1.42 2002/05/05 20:26:02 hal9 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
+
+ 1.1. Quickstart to Privoxy Development
+
+2. The CVS Repository
+
+ 2.1. Access to CVS
+ 2.2. CVS Commit Guideline
+ 2.3. Discussing Changes First
+
3. Documentation Guidelines
+
+ 3.1. Quickstart to Docbook and SGML
+ 3.2. Privoxy Documentation Style
+ 3.3. Privoxy Custom Entities
+
4. Coding Guidelines
4.1. Introduction
4.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
+ 4.7.10. "Uncertain" new code and/or changes to existing code, use FIXME
4.8. Addendum: Template for files and function comment blocks:
-5. Version Control Guidelines
-6. Testing Guidelines
-
- 6.1. Testplan for releases
- 6.2. Test reports
-
-7. 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. Contact the developers
-9. Copyright and History
+5. Testing Guidelines
+
+ 5.1. Testplan for releases
+ 5.2. Test reports
+
+6. Releasing a New Version
+
+ 6.1. Version numbers
+ 6.2. Before the Release: Freeze
+ 6.3. Building and Releasing the Packages
+
+ 6.3.1. Source Tarball
+ 6.3.2. SuSE or Red Hat RPM
+ 6.3.3. OS/2
+ 6.3.4. Solaris
+ 6.3.5. Windows
+ 6.3.6. Debian
+ 6.3.7. Mac OSX
+ 6.3.8. FreeBSD
+ 6.3.9. HP-UX 11
+ 6.3.10. Amiga OS
+ 6.3.11. AIX
+
+ 6.4. Uploading and Releasing Your Package
+ 6.5. After the Release
+
+7. Update the Webserver
+8. Contacting the developers, Bug Reporting and Feature Requests
+
+ 8.1. Get Support
+ 8.2. Report bugs
+ 8.3. Request new features
+ 8.4. Report ads or other filter problems
+ 8.5. Other
+
+9. Privoxy Copyright, License and History
+
+ 9.1. License
+ 9.2. History
+
10. See also
1. Introduction
-------------------------------------------------------------------------------
-2. Quickstart to Privoxy Development
+1.1. 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.
+
+-------------------------------------------------------------------------------
+
+2. 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.
+
+-------------------------------------------------------------------------------
+
+2.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
+2.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.
- 2. A new feature that can be turned off: shoot
+ * 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.
- 3. A clear improvement w/o side effects on other parts of the code: shoot
+ * Don't use the same message on multiple files, unless it equally applies to
+ all those files.
- 4. A matter of taste: ask the list
+ * 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.
- 5. A major redesign of some part of the code: ask the list
+ * 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.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
+
+ 4. ..a matter of taste: 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
-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).
+
+-------------------------------------------------------------------------------
+
+3.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:
+
+<para></para>, paragraph delimiter. Most text needs to be within paragraph
+elements (there are some exceptions).
+<emphasis></emphasis>, the stylesheets make this italics.
+<filename></filename>, files and directories.
+<command></command>, command examples.
+<literallayout></literallayout>, like <pre>, more or less.
+<itemizedlist></itemizedlist>, list with bullets.
+<listitem></listitem>, member of the above.
+<screen></screen>, screen output, implies <literallayout>.
+<ulink url="example.com"></ulink>, like HTML <a> tag.
+<quote></quote>, 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.
+
+-------------------------------------------------------------------------------
+
+3.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.
+
+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.)
+
+-------------------------------------------------------------------------------
+
+3.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.15".
+ 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!
+
-------------------------------------------------------------------------------
4. Coding Guidelines
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.
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
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
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:
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-)
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.
-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------
#include <sys/fileName.h>
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.
-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------
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.
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.
-------------------------------------------------------------------------------
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'.
-------------------------------------------------------------------------------
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.10. "Uncertain" new code and/or changes to exitinst code, use FIXME
+4.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).
-------------------------------------------------------------------------------
Example for file comments:
-const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 1.15 2002/03/30 22:29:47 swa Exp $";
-/*********************************************************************
- *
- * File : $Source$
- *
- * Purpose : (Fill me in with a good description!)
- *
- * Copyright : Written by and Copyright (C) 2001 the SourceForge
- * Privoxy team. http://www.privoxy.org/
- *
- * Based on the Internet Junkbuster originally written
- * by and Copyright (C) 1997 Anonymous Coders and
- * Junkbusters Corporation. http://www.junkbusters.com
- *
- * This program 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.
- *
- * 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.
- *
- * The GNU General Public License should be included with
- * this file. If not, you can view it at
- * http://www.gnu.org/copyleft/gpl.html
- * or write to the Free Software Foundation, Inc., 59
- * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- *
- * Revisions :
- * $Log$
- *
- *********************************************************************/
-
-
-#include "config.h"
-
- ...necessary include files for us to do our work...
-
-const char FILENAME_h_rcs[] = FILENAME_H_VERSION;
+const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 1.42 2002/05/05 20:26:02 hal9 Exp $";
+/*********************************************************************
+ *
+ * File : $Source$
+ *
+ * Purpose : (Fill me in with a good description!)
+ *
+ * Copyright : Written by and Copyright (C) 2001 the SourceForge
+ * Privoxy team. http://www.privoxy.org/
+ *
+ * Based on the Internet Junkbuster originally written
+ * by and Copyright (C) 1997 Anonymous Coders and
+ * Junkbusters Corporation. http://www.junkbusters.com
+ *
+ * This program 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.
+ *
+ * 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.
+ *
+ * The GNU General Public License should be included with
+ * this file. If not, you can view it at
+ * http://www.gnu.org/copyleft/gpl.html
+ * or write to the Free Software Foundation, Inc., 59
+ * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Revisions :
+ * $Log$
+ *
+ *********************************************************************/
+
+
+#include "config.h"
+
+ ...necessary include files for us to do our work...
+
+const char FILENAME_h_rcs[] = FILENAME_H_VERSION;
Note: This declares the rcs variables that should be added to the
"show-proxy-args" page. If this is a brand new creation by you, you are free to
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 $"
-/*********************************************************************
- *
- * File : $Source$
- *
- * Purpose : (Fill me in with a good description!)
- *
- * Copyright : Written by and Copyright (C) 2001 the SourceForge
- * Privoxy team. http://www.privoxy.org/
- *
- * Based on the Internet Junkbuster originally written
- * by and Copyright (C) 1997 Anonymous Coders and
- * Junkbusters Corporation. http://www.junkbusters.com
- *
- * This program 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.
- *
- * 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.
- *
- * The GNU General Public License should be included with
- * this file. If not, you can view it at
- * http://www.gnu.org/copyleft/gpl.html
- * or write to the Free Software Foundation, Inc., 59
- * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- *
- * Revisions :
- * $Log$
- *
- *********************************************************************/
-
-
-#include "project.h"
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
- ... function headers here ...
-
-
-/* Revision control strings from this header and associated .c file */
-extern const char FILENAME_rcs[];
-extern const char FILENAME_h_rcs[];
-
-
-#ifdef __cplusplus
-} /* extern "C" */
-#endif
-
-#endif /* ndef _FILENAME_H */
-
-/*
- Local Variables:
- tab-width: 3
- end:
-*/
+#ifndef _FILENAME_H
+#define _FILENAME_H
+#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 1.42 2002/05/05 20:26:02 hal9 Exp $"
+/*********************************************************************
+ *
+ * File : $Source$
+ *
+ * Purpose : (Fill me in with a good description!)
+ *
+ * Copyright : Written by and Copyright (C) 2001 the SourceForge
+ * Privoxy team. http://www.privoxy.org/
+ *
+ * Based on the Internet Junkbuster originally written
+ * by and Copyright (C) 1997 Anonymous Coders and
+ * Junkbusters Corporation. http://www.junkbusters.com
+ *
+ * This program 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.
+ *
+ * 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.
+ *
+ * The GNU General Public License should be included with
+ * this file. If not, you can view it at
+ * http://www.gnu.org/copyleft/gpl.html
+ * or write to the Free Software Foundation, Inc., 59
+ * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Revisions :
+ * $Log$
+ *
+ *********************************************************************/
+
+
+#include "project.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+ ... function headers here ...
+
+
+/* Revision control strings from this header and associated .c file */
+extern const char FILENAME_rcs[];
+extern const char FILENAME_h_rcs[];
+
+
+#ifdef __cplusplus
+} /* extern "C" */
+#endif
+
+#endif /* ndef _FILENAME_H */
+
+/*
+ Local Variables:
+ tab-width: 3
+ end:
+*/
Example for function comments:
-------------------------------------------------------------------------------
-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
+5. Testing Guidelines
To be filled.
-------------------------------------------------------------------------------
-6.1. Testplan for releases
+5.1. Testplan for releases
Explain release numbers. major, minor. developer releases. etc.
-------------------------------------------------------------------------------
-6.2. Test reports
+5.2. Test reports
Please submit test reports only with the test form at sourceforge. Three simple
steps:
-------------------------------------------------------------------------------
-7. Releasing a new version
+6. 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.
-------------------------------------------------------------------------------
-7.1. Update the webserver
+6.1. Version numbers
-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
+First you need to determine which version number the release will have. Privoxy
+version numbers consist of three numbers, separated by dots, like in X.Y.Z,
+where:
- make webserver
-
+ * X, the version major, is rarely ever changed. It is increased by one if
+ turning a development branch into stable substantially changes the
+ functionality, user interface or configuration syntax. Majors 1 and 2 were
+ Junkbuster, and 3 will be the first stable Privoxy release.
+
+ * Y, the version minor, represents the branch within the major version. At
+ any point in time, there are two branches being maintained: The stable
+ branch, with an even minor, say, 2N, in which no functionality is being
+ added and only bugfixes are made, and 2N+1, the development branch, in
+ which the further development of Privoxy takes place. This enables us to
+ turn the code upside down and inside out, while at the same time providing
+ and maintaining a stable version. The minor is reset to zero (and one) when
+ the major is inrcemented. When a development branch has matured to the
+ point where it can be turned into stable, the old stable branch 2N is given
+ up (i.e. no longer maintained), the former development branch 2N+1 becomes
+ the new stable branch 2N+2, and a new development branch 2N+3 is opened.
+
+ * Z, the point or sub version, represents a release of the software within a
+ branch. It is therefore incremented immediately before each code freeze. In
+ development branches, only the even point versions correspond to actual
+ releases, while the odd ones denote the evolving state of the sources on
+ CVS in between. It follows that Z is odd on CVS in development branches
+ most of the time. There, it gets increased to an even number immediately
+ before a code freeze, and is increased to an odd number again immediately
+ thereafter. This ensures that builds from CVS snapshots are easily
+ distinguished from released versions. The point version is reset to zero
+ when the minor changes.
+
+-------------------------------------------------------------------------------
-Note that make dok creates doc/webserver/user-manual, doc/webserver/
-developer-manual, doc/webserver/faq and doc/webserver/man-page automatically.
+6.2. Before the Release: Freeze
-Verify on the webserver that the permissions are set correctly. Do NOT use any
-other means of transferring files to the webserver.
+The following must be done by one of the developers prior to each new release.
+ * 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. Announce the freeze so that nobody will interfere with
+ last minute changes.
+
+ * Increment the version number (point from odd to even in development
+ branches!) in configure.in.
+
+ * If default.action has changed since last release (i.e. software release or
+ standalone actions file release), bump up its version info to A.B 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 and upload it to the webserver. (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.
+
+ * If the release was in a development branch, increase the point version from
+ even to odd (X.Y.(Z+1)) again in configure.in and commit your change.
+
+ * On the webserver, copy the user manual to a new top-level directory called
+ X.Y.Z. This ensures that help links from the CGI pages, which have the
+ version as a prefix, will go into the right version of the manual. If this
+ is a development branch release, also symlink X.Y.(Z-1) to X.Y.Z and X.Y.
+ (Z+1) to . (i.e. dot).
+
-------------------------------------------------------------------------------
-7.2. SuSE or RedHat
+6.3. Building and Releasing the Packages
-Ensure that you have the latest code version. Hence run
+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.
- cvs update .
-
+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:.
-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
+ 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
- autoheader && autoconf && ./configure
-
+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.
-Then do
+Please find additional instructions for the source tarball and the individual
+platform dependent binary packages below.
- make suse-dist or make redhat-dist
-
+-------------------------------------------------------------------------------
+
+6.3.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
+
+Then do:
+
+ make tarball-dist
To upload the package to Sourceforge, simply issue
- make suse-upload or make redhat-upload
-
+ make tarball-upload
-Goto the displayed URL and release the file publically on Sourceforge.
+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.
-------------------------------------------------------------------------------
-7.3. OS/2
+6.3.2. SuSE or Red Hat RPM
-Ensure that you have the latest code version. Hence run
+In following text, replace dist with either "rh" for Red Hat or "suse" for
+SuSE.
- cvs update .
-
+First, make sure that you have freshly exported the right version into an empty
+directory. (See "Building and releasing packages" above).
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
+As the only exception to not changing anything after export from CVS, now
+examine the file privoxy-dist.spec and make sure that the version information
+and the RPM release number are correct. The RPM release numbers for each
+version start at one. Hence it must be reset to one if this is the first RPM
+for dist which is built from version X.Y.Z. Check the file list if unsure.
+Else, it must be set to the highest already available RPM release number for
+that version plus one.
- autoheader && autoconf && ./configure
-
+Then run:
-Then do FIXME.
+ cd current
+ autoheader && autoconf && ./configure
+
+Then do
+
+ make dist-dist
+
+To upload the package to Sourceforge, simply issue
+
+ make dist-upload rpm_packagerev
+
+where rpm_packagerev is the RPM release number as determined above. Go to the
+displayed URL and release the file publicly on Sourceforge. Use the release
+notes and change log from the source tarball package.
-------------------------------------------------------------------------------
-7.4. Solaris
+6.3.3. OS/2
-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 OS/2
+Setup module:
- ssh cf.sourceforge.net
-
+ cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co os2setup
-Choose the right operating system (not the Debian one). If you have downloaded
-Privoxy before,
+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.
- cd current && cvs update .
-
+Change directory to the os2setup directory. Edit the os2build.cmd file to set
+the final executable filename. For example,
-If not, please checkout Privoxy via CVS first. Verify the version number in
-configure.in. If necessary, change the version number. Run
+ installExeName='privoxyos2_setup_X.Y.Z.exe'
- autoheader && autoconf && ./configure
-
+Next, edit the IJB.wis file so the release number matches in the PACKAGEID
+section:
+
+ PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"
+
+You're now ready to build. Run:
+
+ os2build
+
+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.
+
+-------------------------------------------------------------------------------
+
+6.3.4. Solaris
+
+Login to Sourceforge's compilefarm via ssh:
+
+ ssh cf.sourceforge.net
+
+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:
+
+ 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
+6.3.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:
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
+ cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co winsetup
- autoheader && autoconf && ./configure
-
+Then you can build the package. This is fully automated, and is controlled by
+winsetup/GNUmakefile. All you need to do is:
+
+ cd winsetup
+ make
+
+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.
+
+-------------------------------------------------------------------------------
+
+6.3.6. Debian
+
+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 FIXME.
-------------------------------------------------------------------------------
-7.6. Debian
+6.3.7. Mac OSX
-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 get the Mac OSX
+setup module:
- cvs update .
-
+ cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co osxsetup
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
+Then run:
- autoheader && autoconf && ./configure
-
+ cd osxsetup
+ build
-Then do FIXME.
+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.
--------------------------------------------------------------------------------
+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:
-7.7. Mac OSX
+zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
-Login to Sourceforge's compilefarm via ssh
+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.
- ssh cf.sourceforge.net
-
+-------------------------------------------------------------------------------
-Choose the right operating system. If you have downloaded Privoxy before,
+6.3.8. FreeBSD
- cd current && cvs update .
-
+Login to Sourceforge's compilefarm via ssh:
-If not, please checkout Privoxy via CVS first. Verify the version number in
-configure.in. If necessary, change the version number. Run
+ ssh cf.sourceforge.net
- autoheader && autoconf && ./configure
-
+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:
-Then run
+ cd current
+ autoheader && autoconf && ./configure
- make macosx-dist
-
+Then run:
+
+ gmake freebsd-dist
-which creates a gzip'ed tar archive. Sadly, you cannot use make macosx-upload
+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
+archive to Sourceforge's ftp server and release the file publicly. Use the
+release notes and Change Log from the source tarball package.
-------------------------------------------------------------------------------
-7.8. FreeBSD
+6.3.9. HP-UX 11
-Change the version number of Privoxy in the configure.in file. Run
+First, 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 ...
+Then do FIXME.
-Login to Sourceforge's compilefarm via ssh
+-------------------------------------------------------------------------------
- ssh cf.sourceforge.net
-
+6.3.10. Amiga OS
-Choose the right operating system. If you have downloaded Privoxy before,
+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 && cvs update .
-
+ cd current
+ autoheader && autoconf && ./configure
-If not, please checkout Privoxy via CVS first. Verify the version number in
-configure.in. If necessary, change the version number. Run
+Then do FIXME.
- autoheader && autoconf && ./configure
-
+-------------------------------------------------------------------------------
-Then run
+6.3.11. AIX
- gmake freebsd-dist
-
+Login to Sourceforge's compilefarm via ssh:
-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
+ ssh cf.sourceforge.net
+
+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:
+
+ cd current
+ autoheader && autoconf && ./configure
+
+Then run:
+
+ 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 publicly. Use the
+release notes and Change Log from the source tarball package.
-------------------------------------------------------------------------------
-7.9. Tarball
+6.4. Uploading and Releasing Your Package
-Ensure that you have the latest code version. Hence run
+After the package is ready, it is time to upload it to SourceForge, and go
+through the release steps. The upload is done via FTP:
- cvs update .
-
+ * Upload to: ftp://upload.sourceforge.net/incoming
+
+ * user: anonymous
+
+ * password: ijbswa-developers@lists.sourceforge.net
+
+Once this done go to http://sourceforge.net/project/admin/editpackages.php?
+group_id=11118, making sure you are logged in. Find your target platform in the
+second column, and click Add Release. You will then need to create a new
+release for your package, using the format of $VERSION ($CODE_STATUS), e.g.
+2.9.15 (beta).
+
+Now just follow the prompts. Be sure to add any appropriate Release notes. You
+should see your freshly uploaded packages in "Step 2. Add Files To This
+Release". Check the appropriate box(es). Remember at each step to hit the
+"Refresh/Submit" buttons! You should now see your file(s) listed in Step 3.
+Fill out the forms with the appropriate information for your platform, being
+sure to hit "Update" for each file. If anyone is monitoring your platform,
+check the "email" box at the very bottom to notify them of the new package.
+This should do it!
+
+If you have made errors, or need to make changes, you can go through
+essentially the same steps, but select Edit Release, instead of Add Release.
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
+-------------------------------------------------------------------------------
- make clobber
- autoheader && autoconf && ./configure
-
+6.5. After the Release
-Then do
+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.
- make tarball-dist
-
+-------------------------------------------------------------------------------
-To upload the package to Sourceforge, simply issue
+7. Update the Webserver
- make tarball-upload
-
+When updating the webserver, please follow these steps to make sure that no
+broken links, incosistent contents or permission problems will occur:
+
+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)
+
+That will generate doc/webserver/user-manual, doc/webserver/developer-manual,
+doc/webserver/faq and doc/webserver/index.html automatically.
+
+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.)
+
+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).
+
+Next, commit any changes from the above steps to CVS. All set? Then do
-Goto the displayed URL and release the file publically on Sourceforge.
+ make webserver
+
+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.10. HP-UX 11
+8. Contacting the developers, Bug Reporting and Feature Requests
-Ensure that you have the latest code version. Hence run
+We value your feedback. However, to provide you with the best support, please
+note the following sections.
- cvs update .
-
+-------------------------------------------------------------------------------
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
+8.1. Get Support
- autoheader && autoconf && ./configure
-
+To get support, use the Sourceforge Support Forum:
-Then do FIXME.
+ http://sourceforge.net/tracker/?group_id=11118&atid=211118
-------------------------------------------------------------------------------
-7.11. Amiga OS
+8.2. Report bugs
-Ensure that you have the latest code version. Hence run
+To submit bugs, use the Sourceforge Bug Forum:
- cvs update .
-
+ http://sourceforge.net/tracker/?group_id=11118&atid=111118.
-first. If necessary, change the version number of Privoxy in the configure.in
-file. Run
+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 version, platform, browser, any pertinent log data,
+any other relevant details (please be specific) and, if possible, some way to
+reproduce the bug.
- autoheader && autoconf && ./configure
-
+-------------------------------------------------------------------------------
-Then do FIXME.
+8.3. Request new features
+
+To submit ideas on new features, use the Sourceforge feature request forum:
+
+ http://sourceforge.net/tracker/?atid=361118&group_id=11118&func=browse.
-------------------------------------------------------------------------------
-7.12. AIX
+8.4. Report ads or other filter problems
-Login to Sourceforge's compilefarm via ssh
+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.
- ssh cf.sourceforge.net
-
+New, improved default.action files will occasionally be made available based on
+your feedback. These will be announced on the ijbswa-announce list.
-Choose the right operating system. If you have downloaded Privoxy before,
+-------------------------------------------------------------------------------
- cd current && cvs update .
-
+8.5. Other
-If not, please checkout Privoxy via CVS first. Verify the version number in
-configure.in. If necessary, change the version number. Run
+For any other issues, feel free to use the mailing lists:
+
+ http://sourceforge.net/mail/?group_id=11118.
- autoheader && autoconf && ./configure
-
+Anyone interested in actively participating in development and related
+discussions can also join the appropriate mailing list. Archives are available,
+too. See the page on Sourceforge.
-Then run
+-------------------------------------------------------------------------------
- make aix-dist
-
+9. Privoxy Copyright, License and History
-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
+Copyright © 2001, 2002 by Privoxy Developers <developers@privoxy.org>
+
+Some source code is based on code Copyright © 1997 by Anonymous Coders and
+Junkbusters, Inc. and licensed under the GNU General Public License.
-------------------------------------------------------------------------------
-8. Contact the developers
+9.1. License
+
+Privoxy is free software; you can redistribute it and/or modify it under the
+terms of the GNU General Public License, version 2, as published by the Free
+Software Foundation.
+
+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.
+
+You should have received a copy of the GNU General Public License along with
+this program; if not, write to the
-Please see the contact page in the user-manual for details.
+ Free Software
+ Foundation, Inc. 59 Temple Place - Suite 330
+ Boston, MA 02111-1307
+ USA
-------------------------------------------------------------------------------
-9. Copyright and History
+9.2. History
-Please see the user-manual for information on Copyright and 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 ;-).
-------------------------------------------------------------------------------
10. See also
-Please see the user-manual for others references.
+Other references and sites of interest to Privoxy users:
+
+http://www.privoxy.org/, The Privoxy Home page.
+
+http://sourceforge.net/projects/ijbswa, the Project Page for Privoxy on
+Sourceforge.
+
+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 "Privoxy - Submit Filter Feedback" to submit "misses"
+to the developers.
+
+http://www.junkbusters.com/ht/en/cookies.html
+
+http://www.waldherr.org/junkbuster/
+
+http://privacy.net/analyze/
+
+http://www.squid-cache.org/
+
+
projects / privoxy.git / blobdiff