The Linux Console Tools

Contents

The Art of Patch

I have recently received a growing number of patches.

In order to make it easier (mainly for me ;-) to integrate them, here are a couple of hints that should not raise much the workload for the submitters, but will reduce the maintainer's workload, thus allowing more patches to be reviewed/integrated in a minimal delay.

Code contributions

  • Don't run diff against your working space, but first run "make distdir", and then run diff against the console-tools-* dir just created. This will omit all sorts of useless files from the diffs.
  • When addressing several issues, try as much as possible to issue one patch per feature, to ease the patch review and integration.
  • To produce the diffs, use a command line like:
    diff -ruN -xconsolefonts <dir1> <dir2>
    

Large related data sets

Sets of related data files can be defined as using a common specific script. Examples of such scripts are latin, cyrillic, korean, chinese, japanese (although these last two ones are more complex, sharing some glyphs), etc.

Those should probably be packaged as separate data packages. This means that the current console-data package may not stay as it is. For this reason, I do not plan to include such large data files in console-data, but rather to have guidelines defined for such data packages, which would be better maintained by people using the relevant scripts.

Fonts contributions

Just (tar and) compress them using gzip or bzip2, since we don't have yet a suitable source-format for these [yes, I planned to work on this quite a long time ago already].

Keymap contributions

  • Be sure that you keymaps explicitely define all keys of your keyboard, so that people loading it after loading a (perhaps erroneous) other keyboard can still be sure to get all keys you intended your keymap to provide.
  • Be sure to use the relevant include statements in your keymaps, so that it can share the most possible parts with other related ones. This will increase readability, save disk and archive space, ease coherence of future enhencements, and perhaps make you look even more sexy :)

Fallback tables

I'd definitely value contributed fallback tables. The current ones may be useful, but surely do not cover the needs of every user.

ACM, SFM and the like

Application's Charset Map (ACMs)
If you really want to have one included now, just send it, I'll include it. If you have programming skills, a much better contribution would be to allow the tools to read glibc locale definitions.
Screen-Font Maps (SFMs)
Those are font-specific. There are useless without a font, and should be embedded in a PSF file. The only reason why some are still provided standalone are because not all provided fonts have valid bultin SFMs, and those file can help interested people to fix those.
Old 8-bit Font-to-Charset Maps (FCMs)
These ancestors to ACMs are obsolete. I suppose nobody still needs one. If you feel you really need one, maybe your specific needs need be addressed by enhencements to the tools - just get in touch.

Yann DIRSON
This page last modified: Wed Oct 20 01:19:58 1999
Template last modified: Mon Feb 18 00:22:53 2002
Sourceforge