Next: , Previous: Top, Up: Top


1 About the Gnits Standards

See Preface.

The Gnits Standards are a collection of habits, and their descriptions, willfully chosen by a small group of maintainers calling themselves the GNU nit-picker gang. The word `Gnits' refer to the gang, not the standards they decided to use, even if this little confusion is quite understandable, and excusable.

More than a standard, Gnits is a small group of maintainers interested at nit-picking at others, or being nit-picked by them. In fact, it evolved out of a kind and relaxed friendship between a few maintainers. We use our little group to let the steam or frustrations get out, once in a while, and might discuss of many unexpected things, really, yet usually related to our maintenance work. The level of discussion is frank to the point many things would be hardly publishable... In fact, Gnits is a small group of people having really done a lot of work together for years. The mailing list quoted below exists only as a convenience between us.

The point behind Gnits Standards is that the GNU Standards don't actually specify enough detail. In a way, Gnits Standards start where the GNU Standards leave off. Since Gnits Standards are only meant to supplement GNU Standards themselves, sometimes to an excruciating level of detail, we decided to lay out this manual exactly using the same structure GNU Standards have, just for easing cross referencing from here to there. Many sections here are left empty, so the numbering stays identical in both printed manuals. When new sections are needed here, they are added at the end of chapters instead of a place that might be more logical, only to preserve the numbering correspondence between sections.

Let us insist on the fact that Gnits Standards are in no way normative in GNU. Only real, genuine GNU Standards are. GNU maintainers do not have to follow Gnits Standards if they do not feel like it. Nevertheless, they might find in Gnits Standards good ideas on the way to follow GNU Standards themselves, as well as tentative, non-official explanations about why some GNU Standards were decided the way they are.

There are very few discrepancies between Gnits Standards and GNU Standards, and they are always well noted as such. So there is very little chance that, by reading this manual, you would be inadvertently induced into disobeying GNU Standards. Moreover, it would be sad if GNU Standards were massively importing Gnits Standards, and this might turn off contributors by what they deem to be excessive requirements in GNU.

Besides C programming, Gnits Standards want to address problems in writing shell scripts, m4 code and Perl scripts. And many other things!

Opinions or suggestions regarding this document may be sent to gnits@gnu.org. However, please keep in mind this manual just represents the common choice of a few people only, and is not normative in the GNU project. So, there is no real point in trying to deeply debate Gnits Standards. Moreover, the gnits address is kind of private, the goal of Gnits Standards is a mean for us to work faster and nevertheless feel satisfied with the results of our work. If we were induced in great debates, or if the gnits list was becoming public, I fear the whole thing would slow us down far more than it helps.

If you really feel like contributing to GNU, you might jump in, and do things yourself. Consider the GNU tasks list, available for ftp on gnu.org in pub/gnu/standards/ and see if some project would interest you enough for raising your commitment to it. Most projects require a lot of time to achieve successfully. Write to gnu@gnu.org for involving yourself.

This release of the Gnits Standards was last updated March 1, 2005.