//$Id: RULES.TXT 1.4 1997/11/18 04:24:59 ska Exp $
Hi,

this is Steffen Kaiser speaking, in his role of the maintainer of the
CLibrary project. Well, frankly speaking, to me this is neither an honor
nor a shame. All I say/write/state is meant as it said/written/stated,
no more & no less; except marked by a smiley!

Below the rules some remarks on the e-mail account are given.

To make my job easier (for me) I'll rise some rules, they will apply as
long as I maintain the CLibrary and don't receive too much complains
about them. Don't take me wrong, I won't reject somebody's opinion/work
only for breaking these rules (except I.1). They shall help to make
maintaining the library easier and more clear and, therefore, more
efficient for you and me.

I. Licence
==========

I.1. All the code in this library is covered by the GNU General Public
Licence (GPL) or, that's a matter of discussion of the FreeDOS society, the
GNU General Library Public Licence (GLPL). Any code that is protected
by other licenses, even if they may be comparable to G(L)PL, are rejected,
depending on the quality and the requiredness of the sources with or
without a prior request to the author by maintainer.

I.2. Code that is Public Domain is reverted into G(L)PL with a note about
its freeness and the unchanged file is placed into the CONTRIB directory.

I.3. Any author donating source(s) automatically agrees with the G(L)PL,
except otherwise stated in the source(s) and ensures that s/he has the
right to donate the source(s).

II. The C standard library
==========================

II.1. That's the thing providing the core set of functions in the
programming language C. It will follow the ANSI C specification (ISO 9880),
the addition POSIX.3 (as much as is applicable in the DOS environment) and
additions for portability with present DOS C compilers.

II.2. The library may be called CLibrary or CLib.

II.3. CLib should be written in the programming language C and portable
as much as possible. Only some files/functions are accepted to be written
in assembly.

II.4. The files CONF/_CLIB*.C define control strings that contain the
revision of the CLibrary.

II.5. In addition to the functions written in C, functions in assembly
my be donated for optimization purpose. But these functions must conform
to the associated C function.

III. The maintainer
==================

III.1. That's me, unless stated otherwise.
Currently available via e-mail only, by this account:
Steffen.Kaiser@fh-rhein-sieg.de

III.2. There is exactly one maintainer.

III.3. My native language is German, and to anybody asking me whether or
not I can speak English I reply "No, no single word". Just to make sure
s/he may not expect anything. That also means that I definitely need
somebody to revise the remarks in the CLibrary itself and the sources.

III.4. Bugs, bugfixes, donations, suggestions, corrections in spelling,
grammar, politcal correctness,& interpretation of the standards are to
send to me. I'll forward them to the author and anybody else involved.
Note: Some authors may not want to be bothered because of old code or
are no longer available or the author would receive thousands of
flame mails or or...

III.5. The purpose of the maintainer of CLib is to collect the sources,
to pack distributions, to hold contact with the authors, to assign
work to people who want to do something within the CLib project, to
answer & issue questions about CLib.

III.6. The maintainer is in_flame_able. So direct any flames directly to
the maintainer instead towards the authors or the FreeDOS society.

IV. The authors
================

IV.1. That are all of you (& me) who have donated source(s).

IV.2. No source is considered to be complete at any state/revision of
the CLibrary. Any corrections of, remarks on,& suggestions to the code
are meant to help to improve the quality of CLib, but not the wish to
offend or insult the author. This rule applies to all and everybody
regardless of the author's (in alphabetical order) age, colour of eyes,
gender, origin, planet of birth, programming abilities, race or
relationship to somebody (including Lady Di, Bill Gates and me).

IV.3. Donated source(s) shall honor the coding style (DOC/CODING.TXT).
Because to support non-smart linkers it's best to put each function into
its own file. In this case you can use a slightly different file layout
as described in the file CHEAD. If you don't, take the first comment of
this file, but put the function descriptions as described in
DOC/CODING.TXT.  Fill in your name in the .C header's comment section
"Origin". Place the donation date there.

IV.4. If two or more authors donate the sources of the same function,
that one is picked that seems to suites the necessaty best.

IV.5. Authors are not oblidged to maintain donated sources. But they
will be informed about any suggestions, remarks,& bugfixes unless
stated otherwise toward the maintainer.

IV.6. With the act of donating source(s) the author automatically agrees
that the source(s) are modified to conform to the coding style, the
formatting and documenting without further notification of the author.
Also the source(s) may be renamed or placed into different sections of CLib.

IV.7. If you have received sources from other people, but they don't
like to be mentioned, consider yourself as the donator/author.

IV.8. To use other G(L)PL'ed sources is welcome. Make any necessary
changes, prepend the standard header, place your name and a "based upon"
or "derived from" line into the "Origin:" section,& put the unmodified
file into the CONTRIB directory.

V. The revisors
===============

V.1. That's anybody who revised an already donated source. Any author
may & should become a revisor.

V.2. Any revisor will pick a two or three letter callsign and marks
any comments with this sign. Already assigned callsigns are listed in
DOC/CALLSIGN.TXT.

V.3. Revised source(s) are to send to the maintainer, not to the
author or former revisor. Ship one changelog for all revised files
containing one-line descriptions what you did.

V.4. Revise only source(s) directly taken from an official release from
the maintainer. Don't revise a source that has been revised, but has not
been re-inserted into CLib.

V.5. Whenever a source is modified, place your callsign at the first
place of the "Revised by" section in the .C file's comment header, along
with the date. This entry may be removed by the maintainer, if the
modifications are no "real" modifictions, but comments, suggestions etc.

V.6. You may alter the RCS version information as you wish. But don't alter
the string after:	"File Revision".

V.7. If a revised source is a complete rewrite rather than an
improvement, this source will become "donated" status. The former source
will be moved into the OLDSRC section.

V.8. If more than one revisor modify the same source, the modifications
are merged. If the same modification appears more than once, the first
arrival's revisor is listed in the "revised by" section.

V.9. Revisors are not informed whether or not their suggentions/remarks/
bugfixes are/will be incorporated into the source. But possibly they will
be contacted to explain, when there are misunderstandings.

V.10. Any revisor has to document weak and even weakest points in the
implementation regardless how rare the condition may come up.

V.11. Modifications to the code are to comment with this syntax:
	/* ...remark... - <date> <callsign>*/
Note: There is one space before but none behind the callsign.
The modificator's ID will be removed, if the comment is a source comment
rather than a suggestion or comment of more general purpose.

V.12. Modified sources may be shipped either as complete files or
as diffs created by GNU diff: "diff -u1 old\FILE.c FILE.c >FILE.dif"

V.13. Revising a source code is not only dedicated to find bugs,
comments, remarks or suggestions, but also to verify that there are _no_
such things to tell. In this case the file revision is the only
necessary information to note down.

V.14. Note down the CLib version into the acompanying changelog. This
is required to keep track of any changes and numerous distributions.

VI. The sources
===============

VI.1. That are the .C, .H,& .* files forming the CLibrary.

VI.2. Each source file contains revision control information, maintained
by the GNU RCS package. This information is independed on any revision
control system an author might use.

VI.3. Each source file defines one function and its accompanying 'static'
functions. One source file may contain both one function and one or more
externally accessable variables, if a) any useage of the variables
requires the usage of the function,& b) the variables are never used
apart from each other.
You may place function #1 into the source of function #2, if
1) function #1 can be used only (no exception), if function #2 is used.
2) function #1 immediately wraps function #2, e.g.:
... fct1(...)
{	[return] fct2(...);	}

VI.4. Header files are to be separated into files to be published and
files used while making CLib only.

VI.5. Authors may assume that revisors are able to _read & understand_
any C expression and statement, regardless whether or not the revisor
would write the expression the very same way.

VI.6. Fundamental changes of the internals of CLib will be discussed
openly on the FreeDOS mailing list. Outdated sources are hold in the
OLDSRC section of CLib.

VI.7. Because the CLib will be linked to most of the C programs, the
CLib must forsee and act correctly in any state of the OS. How unusual
the condition may come up. In some situations the developer of CLib may
consider that the condition possability is very rare and it will be
better to ignore it, in this case this waekness has to be documented.

VII. The documentation
======================

VII.1. That's the work most programmers hate most.

VII.2. Any part of CLib will be documented. General, fundamental decisions
will be documented and described in the DOC section of CLib. Individual
information is placed in the particular section or the source file itself.

VII.3. The fundamental documentation shall describe how the CLib performs 
the internal work, where this CLib differs from others and what compiler
dependencies exist.

VII.4. The documentation within the section describe a) how exactly the
internal data structures are choosen & why, marks advantages and
disadvantages. The algorithm that is performed; b) the _why_ some
way of coding was choosen to be comparable to ways other authors may
think of. Also note down other algorithms, just in case in a latter
state of the implementation they are needed.

VII.5. The primary language is English. Sources are to be commented in
English. External documentation may be translated into other languages.
This is recommended as the majority of programmers understand English.

VII.6. The file DOC/KNOWNBUG.TXT contains all known bugs, weak points and
collisions of CLib with itself and other DOS C compilers. Any revisor
is welcomed to remark this file as well.

VII.7. The date has this format: yyyy/mm/dd. This should remove the
problem to differ dd/mm/yyyy from mm/dd/yyyy. The "/" may be any
punctation character.

==================

Please report anything regarding CLib to: Steffen.Kaiser@fh-rhein-sieg.de
This account will accept e-mails upto 1MB in size. If your mail exceeds
this limit, make this package available via HTTP or FTP and send a 
short note.

If you have no possability to place files accessable via FTP or HTTP,
you can, of course, slice them.

I can handle any archives as well as mail-encoding commonly used in Unix
or DOS. Don't send long filenames, stick to DOS's 8.3 names.

Begin the subject line with "CLIB".

For fixes & bugs use as the <one-line description> what the bug causes or
when it is triggered, not why or how it had been fixed.
