Concerning rcron, you don't actually need explicit support for it, as it's just part of the scheduled command. However, some integration could make it obscenely pleasant to use. Probably, i would need to manually set up rcron on a group of servers, then configure some sort of 'virtual server' in the hub which contains the servers in the group. When i schedule a job on the virtual server, it is added to the crontabs on all the real servers, but guarded with rcron, so it only executes on one. The reporting would then deal with the fact that only the master in the group actually runs the job: if the rcron wraps the minicron, then it would deal with the fact that only one server sent a report; if the minicron wraps the rcron, it would just hide the empty reports from the non-master servers.
We currently manage most of our cron jobs through Puppet. If we adopted minicron, we'd want to keep doing that. That means we would write a Puppet defined type which adds a job in the hub. It would be really useful if there was an API, or ideally a command-line tool, to do that. It would be nice if there was then an easy way to distinguish Puppet-managed and interactively defined jobs in the hub, so that people didn't attempt to fiddle with the Puppetted ones. Maybe a flag that makes them read-only in the UI, but allows them to be managed in the API? That's probably something we would address in a fork if we did adopt minicron.
Some kind of auditing for changes to job definitions would be useful. We currently use Jenkins for ad-hoc scheduled jobs, and our very weak audit trail for it is a recurrent pain point. Would it make any sense to keep job definitions in a Git repository? Might be quite a pain to provide an interactive UI on top of that, though.
