proidiot / gone Goto Github PK

In addition to gofmt, we should also run golint during the Travis CI checks.

It would be nice to have a log coverage tool that will indicate whether all paths in a piece of code actually write logs. It might need to be specific to this particular codebase at least at first, but that should be fine.

Add badges for Travis, Coveralls, Godoc, and Waffle.

There doesn't appear to be a nice way of creating error constants even though it seems to be rather easy to do so. You can create package-level error variables, but the C programmer in me is uncomfortable with the blatant lack of const-correctness in this setup.

As with so many languages of late, Go seems to have created a pretty awful looking logging system in an effort to "improve" on the (admittedly imperfect) syslog approach. It seems as though people cannot resist creating absurdly complex minimum log setup requirements in a misguided effort to get the finer administrative details of log delivery out of the hands of systems administrators and into the hands of developers, even if they must abandon all hope of using an intelligible abstraction in order to do so. Furthermore, Go (as with so many other languages) have seen fit to abandon the standard syslog levels in favor of yet another combination of log levels unique in the entire world of logging, and not exactly fitting anyone's use case except the small number of people who were locked in the room where this half-baked decision was made.

There are many faults with syslog, but its practical advantages are unmatched. It has sane defaults that allow developers to start developing without worrying about matters that are strictly in the realm of systems administration anyway. It has well known and fairly well understood log levels that do indeed make a lot of sense (even if some developers are bothered by the fact that they've never written code which could conceivably justify the use of some of these log levels). The log format is the one and only format that is understood by every other log aggregation system in existence, and this fact is even more jarring when you consider that no other format is supported by even half as many log aggregation and analysis systems. Further, just about the only log system that is simpler to use is basic writing to stderr.

Unfortunately it seems that Go's implementation of the syslog client calls are not as clever or as graceful in the face of failures as C's syslog calls. It would be nice to have a variant of the syslog calls which are global by default in much the same way as in C, and will not necessarily fail in the event that the syslog daemon is not running, but will instead only write to stderr if that is what was requested at runtime (say, via environment variables). The details of where logs go, what level of logging we save, whether or not we want just stderr or just syslog daemon or both or either depending on which is available should all be controlled at runtime by an administrator, and the developer need only make calls to the subsystem as though writing to stdout or stderr directly.

There should be a doc.go for every package, but this isn't currently true.

The Travis CI tests should give more meaningful output.

Add gofmt check to Travis so that things don't get out of hand.

A changelog should be added (i.e. http://keepachangelog.com).

Golang examples should be added for everything.

The script which checks every file against gofmt -s runs against all files and not just the relevant ones. For its initial use within Travis Ci, this is fine, but the same script couldn't necessarily be used as a pre-commit hook for local development, but there's no reason it couldn't be modified for use in this context.

Get coverage back to 100%

LOG_PERROR is a very common non-POSIX option among syslog implementations,
and the default behavior (at least in Linux, and likely in others) is to
append a newline (a literal byte 0x0a) iff that is not already the last
byte of the message. However, this implementation does not currently have that
behavior.

Continuous integration is needed.