-
Notifications
You must be signed in to change notification settings - Fork 7
/
BYLAWS
executable file
·132 lines (98 loc) · 4.66 KB
/
BYLAWS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
ZFL Bylaws
==========
Goals
-----
The principal goal is to aggressively reduce the LoC in 0MQ devices and other
applications written in C, and leave the resulting code 100% portable. A
secondary goal is to recycle decades of experience from legacy iMatix C
libraries so it can be used for new applications.
Vision
------
Lightweight, class-based, minimalistic, highly efficient, aimed at making it
faster and easier to develop realistic, secure, and portable 0MQ devices and
applications. Easy to learn, consistent API, and extremely thin.
Packaging
---------
ZFL uses autotools for packaging.
Scope
-----
The primary scope of ZFL is writing robust services (devices and other headless
applications). Services need configuration file parsing, integration with the
operating system, logging, remote administration, process security, etc. ZFL is
not intended as a general purpose C library, though it provides some basic and
widely-used data structures. Every module in ZFL is backed by a clear use case
that justifies its inclusion in the library. Functionality for "its own sake"
will be removed.
Overall Structure
-----------------
ZFL consists of modules, each module consisting of a .h and a .c. Modules may
depend on other modules. Each module (in general) maps to a class.
zfl.h will include all modules header files, all the time. For the user, ZFL
forms one single package. All modules start by including zfl.h. All
applications that use ZFL start by including zfl.h.
zfl.h will include all necessary system header files. For the user, ZFL pulls
in all system dependencies automatically and makes these available to
applications as well as ZFL code.
zfl.h defines a limited number of small, useful macros and typedefs that have
proven useful for writing clearer C code.
Memory leak testing
-------------------
To test against memory leaks we use the mtrace tool under Linux. The
zfl_selftest.c program calls MALLOC_TRACE, which zfl_prelude.h sets to mtrace()
under Linux. This is how we build and run the selftests with mtrace:
----
# Run selftests and check memory
gcc -g -o zfl_selftest zfl*.c -lzmq
export MALLOC_TRACE=mtrace.txt
zfl_selftest -v
mtrace zfl_selftest mtrace.txt
----
Git Workflow
------------
The ZFL project uses this minimalistic Git workflow:
* The 'stable' branch is the last stable release
* The 'master' branch is the next release candidate
* The 'unstable' branch is the leading edge
All patches are submitted as issues to the Git repository, with code in the
issue or as gists.
Source Style
------------
We consider the ZFL source code to be valuable, and readability to be its most
important feature. The canonical example for ZFL style is the zfl_base module,
which defines the template for all other modules. We consider a module to be
"perfect" when the reader cannot distinguish its style from that of zfl_base.
The nomenclature for all modules is consistent:
* Source files: zfl_base.c, zfl_base.h
* Methods: zfl_base_test, zfl_base_print
Some modules are not class based. Class-based modules follow these rules:
* Class typedef: zfl_base_t
* Constructor: zfl_base_new
* Destructor: zfl_base_destroy
* Property methods: zfl_base_property_set, zfl_base_property
* Class structures are private (defined in the .c source but not the .h)
* Properties are accessed only via methods named as described above.
* In the module source code the object is always called 'self'.
* The constructor may take arbitrary arguments, and returns NULL on failure, or
a new object.
* The destructor takes a pointer to an object reference and nullifies it.
Return values for methods are:
* For methods that return an object reference, either the reference, or NULL on
failure.
* For methods that signal success/failure, a return value of 0 means sucess, -1
failure.
Private/static functions in a class are named s_functionname and are not
exported via the header file.
All modules have a test method called zfl_classname_test.
Contributions
-------------
All contributors are listed in AUTHORS. All git committers agree in advance
that they license their contributions under the LGPL, that they are the original
authors of their work, or that they can certify the origin of the code.
All modules are maintained by a single person, who is the responsible editor for
that module and who is named in the header as such. This is usually the
originator of the module. Whereas several people can collaborate on a module,
one single person is always the lead maintainer and the one to blame when it
breaks.
The general rule is, if you contribute code to ZFL you must be willing to
maintain it as long as there are users of it. Code with no active maintainer
will in general be deprecated and/or removed.