On Sat, Jun 11, 2011 at 8:28 PM, Jim Trocki <troc...@gmail.com> wrote:
> On Sat, 11 Jun 2011, Nico Kadel-Garcia wrote:
>
>> Is there a central code base now for updates? The Wiki and codebase at
>> https://mon.wiki.kernel.org/index.php/Main_Page/ seems to have last
>> been updated in 2007. I do see some published patches, mostly from
>> Nathan....
>
> the most recent code is available from cvs.
>
> http://sourceforge.net/scm/?type=cvs&group_id=170

Thanks!!!! Given that the published tarball is from 2007, perhaps it's
time then to collect some patches and do a minor update release? And
what are the chances of getting that shifted over to Sourceforge's
supported "git" access, to allow people like me to do local patchind
and tweaks and branching and submit the changes when we're ready?

I've helped migrate CVS or Subversion projects on Sourceforge to the
git access before. It's quite easy, and works well. It also helps
encourage minor upgrades to be submitted.

>> I'm also running into issues with daemontools integration rather than
>> the normal init scripts published by my supported Linux distribution
>> (which I've been trying to integrate per a local demand), and would
>> happily publish notes for it.
>
> sure, whatever you have that may be helpful to others is welcome. post
> it to the mailing list, and we'll incorporate it into cvs.

I'm just working out some details of integrating it with the
"daemontools-run" package. Debian and its derivatives are publish mon
with a standard init script: they also provide that daemontools
toolkit.

>> I'm also running into issues with "monshow" output clipping the names
>> of services and groups automatically to align the columns, which makes
>> descriptive service names kind of tough to use. Has anyone published a
>> tweak to "monshow" to create more verbose output?
>
> yes, it uses perl's "format" feature for textual output, and the format
> definition will truncate a field which is too long. one could change
> the format definition to allow for a wider field, or change the textual
> output code to dynamically size the column width, or to use something
> other than the built-in "format" mechanism.

Yeah, something like tab separated values or evern simple HTML tables
would be preferable. Having several tests with longish description
names makes them indistinguishable in that "format" ouput. In
practice, one should not accept input values that one has no way to
*output*.

_______________________________________________
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon

Reply via email to