On 03/02/2014 09:05 PM, Vladimir Vuksan wrote:
I like the fact that Github Wiki's are just another Git repo.
Perhaps we ought to figure out if we can use github pages to serve
Wiki's directly e.g. something like
wiki.ganglia.info
Anyone know ?
I like the idea of docs.ganglia.info or
Why don't we convert the sourceforge trac wiki in to Jekyll pages and serve
them via Github?
--Nick.
On Mon, Mar 3, 2014 at 2:05 AM, Vladimir Vuksan vli...@veus.hr wrote:
I like the fact that Github Wiki's are just another Git repo.
Perhaps we ought to figure out if we can use github pages
Works for me. Now we just need a
volunteer :-D
On 03/03/2014 04:23 PM, Nick Satterly wrote:
Why don't we convert the sourceforge trac wiki in
to Jekyll pages and serve them via Github?
--Nick.
On 03/03/14 22:31, Vladimir Vuksan wrote:
Works for me. Now we just need a volunteer :-D
This could be a fun exercise for testing one of the GSoC applicants,
maybe they can write a small script to scrape and convert the content
+1
On Mon, Mar 3, 2014 at 9:44 PM, Daniel Pocock dan...@pocock.com.au wrote:
On 03/03/14 22:31, Vladimir Vuksan wrote:
Works for me. Now we just need a volunteer :-D
This could be a fun exercise for testing one of the GSoC applicants,
maybe they can write a small script to scrape and
On 01/03/14 22:54, Ben Hartshorne wrote:
I've changed my mind about reorganizing the repo. The correct way to
summarize different approaches to the same problem is through documentation
(aka the wiki) not repository organization. It makes sense to keep self
contained projects (like
I like the fact that Github Wiki's are just another Git repo.
Perhaps we ought to figure out if we can use github pages to serve
Wiki's directly e.g. something like
wiki.ganglia.info
Anyone know ?
Vladimir
On 03/02/2014 04:01 AM, Daniel Pocock wrote:
On 01/03/14 22:54, Ben Hartshorne
I've changed my mind about reorganizing the repo. The correct way to
summarize different approaches to the same problem is through documentation
(aka the wiki) not repository organization. It makes sense to keep self
contained projects (like ganglia-nagios-bridge) as its own repo for ease of
forks
Actually, looking at the code, it looks the the message type is explicit, so
you wouldn’t need any configuration:
msg-version != EBT_ULOG_VERSION
On Mar 1, 2014, at 1:54 PM, Ben Hartshorne gang...@green.hartshorne.net wrote:
I've changed my mind about reorganizing the repo. The correct way to
Please ignore the non sequitur - I accidentally sent this reply to the wrong
email thread.
On Mar 1, 2014, at 2:30 PM, Peter Phaal peter.ph...@inmon.com wrote:
Actually, looking at the code, it looks the the message type is explicit, so
you wouldn’t need any configuration:
msg-version !=
On 25/02/14 00:39, Ben Hartshorne wrote:
I was planning on writing a README comparing them (so it's visible at
the directory / repo level that houses all the various incarnations)
but a wiki page might be better. I like the README because it's right
there when you're browsing for the code but
On 24/02/14 17:59, Ben Hartshorne wrote:
Hi,
There are several different methods of connecting nagios to ganglia in our
github repo:
* https://github.com/ganglia/ganglia-web/tree/master/nagios
* https://github.com/ganglia/ganglia-nagios-bridge
*
I was planning on writing a README comparing them (so it's visible at the
directory / repo level that houses all the various incarnations) but a wiki
page might be better. I like the README because it's right there when
you're browsing for the code but a wiki provides more flexibility. Maybe
the
13 matches
Mail list logo
