view release on metacpan or  search on metacpan

unzip-6.0/proginfo/ZipPorts  view on Meta::CPAN

__________________________________________________________________________

  This is the Info-ZIP file ZipPorts, last updated on 17 February 1996.
__________________________________________________________________________


This document defines a set of rules and guidelines for those who wish to
contribute patches to Zip and UnZip (or even entire ports to new operating
systems).  The list below is something between a style sheet and a "Miss
Manners" etiquette guide.  While Info-ZIP encourages contributions and
fixes from anyone who finds something worth changing, we are also aware
of the fact that no two programmers have the programming style and that
unrestrained changes by a few dozen contributors would result in hideously
ugly (and unmaintainable) Frankenstein code.  So consider the following an
attempt by the maintainers to maintain sanity as well as useful code.

(The first version of this document was called either "ZipRules" or the
"No Feelthy ..." file and was compiled by David Kirschbaum in consulta-
tion with Mark Adler, Cave McNewt and others.  The current incarnation
expands upon the original with insights gained from a few more years of
happy hacking...)


Summary:

  (0) The Platinum Rule:  DON'T BREAK EXISTING PORTS
(0.1) The Golden Rule:    DO UNTO THE CODE AS OTHERS HAVE DONE BEFORE
(0.2) The Silver Rule:    DO UNTO THE LATEST BETA CODE
(0.3) The Bronze Rule:    NO FEELTHY PIGGYBACKS

  (1) NO FEELTHY TABS
  (2) NO FEELTHY CARRIAGE RETURNS
  (3) NO FEELTHY 8-BIT CHARS
  (4) NO FEELTHY LEFT-JUSTIFIED DASHES
  (5) NO FEELTHY FANCY_FILENAMES
  (6) NO FEELTHY NON-ZIPFILES AND NO FEELTHY E-MAIL BETAS
  (7) NO FEELTHY E-MAIL BINARIES


Explanations:

  (0) The Platinum Rule:  DON'T BREAK EXISTING PORTS

      No doubt about it, this is the one which really pisses us off and
      pretty much guarantees that your port or patch will be ignored and/
      or laughed at.  Examples range from the *really* severe cases which
      "port" by ripping out all of the existing multi-OS code, to more
      subtle oopers like relying on a local capability which doesn't exist
      on other OSes or in older compilers (e.g., the use of ANSI "#elif"
      or "#pragma" or "##" constructs, C++ comments, GNU extensions, etc.).
      As to the former, use #ifdefs for your new code (see rule 0.3).  And
      as to the latter, trust us--there are few things we'd like better
      than to be able to use some of the elegant "new" features out there
      (many of which have been around for a decade or more).  But our code
      still compiles on machines dating back even longer, at least in spirit
      --e.g., the AT&T 3B1 family and Dynix/ptx.  Until we say otherwise,
      dinosaurs are supported.


(0.1) The Golden Rule:  DO UNTO THE CODE AS OTHERS HAVE DONE BEFORE

      In other words, try to fit into the local style of programming--no
      matter how painful it may be.  This includes cosmetic aspects like