March continues to be a busy month. Most of the work done was internal, although a few definitions managed to make it out the door.

Done:
- - - - - - - -
+ New definitions: redis-server, ahcpd, mongodb, quake-server, famd, gunicorn, mdadm

+ Revised definitions: rpcbind (now includes a ./check script from Luke Diamand, thanks!)

+ The logging schema has been fleshed out to support daemontools and s6. It remains untested at the moment.

+ New! Experimental option for logging called "autolog", a script that guesses at the logging to be used by looking at the framework in use. This option is not enabled by default and is considered experimental. If it works well, it may become the new default and replace the current policy of setting the sv/.log/run symlink to /bin/true.

+ Took a first pass at splitting up documentation into separate files. I also updated some of the troubleshooting documentation as it was referring to removed code.

+ Cleaned up remaining scripts, code, comments, and naming conventions.


In Progress:
- - - - - - - -

+ More definitions! For instance, I'm sitting on a pile of patches for rpc-related services (read: support for NFS) and it still needs to cook a bit more before it's done.

+ The only non-template definitions left are: autofs, bind, bluetoothd, dbus, dhcpd, lwresd, postfix, wicd, and ypbind. They all need some attention.

+ 3 services have broken flags: munin-node, quake-server, and redis-server. Munin has structural issues, quake-server and redis-server need additional configuration.

+ Design notes. I took an initial stab at it but I don't like the structure/layout. Not enough "why", too much "the history of it means X". Needs more refinement.

+ Clean up untested definitions, as part of the push for the 0.1 release. Many of the definitions have met the minimum test requirements and I've not cleared out the "untested" marker. The current criteria for being tested is (a) the service launches cleanly (b) the service does not complain beyond warnings in its logs (c) the service appears to function as intended.

+ ...and of course, enough new definitions to justify a 0.1 release. This means at least 122 *tested* entries in sv/ must be present, which is about 10% of the count of init.d scripts used by Debian 7. There are currently 96 entries but many are for getties, so after deducting 18 redundant entries that leaves 78 definitions, which means I need to make 44 entries. Worst case, I end up with a 0.1 release candidate.


Still To-Do / Experimental:
- - - - - - - -
+ Think about ways to incorporate perp, which uses a different format of ./run file. With the recent switch to support /bin/sh vs execline, this is a real possibility now. That means sv/.run/run-sh, sv/.run/run-execline, and now sv/.run/run-perp will become potential targets for sv/.run/run. Madness, I tell you, madness!

+ Examine nosh.  This is going take a bit of time to digest...

+ Re-think/re-work the ./needs directory. While nosh already has a similar concept, I want to be able to support Laurent's future efforts as well.

+ Prepare to re-license the project as BSD when I approach the 0.2 release, or approximately 244 entries. The entire point of the current MPL2.0 license was to make contributions "sticky" enough to the project until such point that it had some critical mass. When I reach over 240+ definitions, the project should be able to accommodate the needs of a majority of people, so I won't have the same kind of need anymore, and can re-license the scripts to something much more permissive.

+ Once my project is BSD licensed, I might be able to merge / hybridize / collaborate-on some of Toki's work (see below), completely supplanting the existing sv/.run/run-sh arrangement. Or not. Or, something...we'll just have to wait and see.

+ Support a modified version of usersv[1]. While scripted support for user-defined process management will still be present, it would be nice to see usersv expanded to support other frameworks, and not just runit alone. This would give a passive (admin controlled) or active (user controlled) option.

[1] https://github.com/eichlan/usersv

Reply via email to