[Ganglia-developers] moving mod_multicpu out of ganglia to ganglia-modules-linux
The mod_multicpu code in the main ganglia repo is Linux-only, while most of the other modules are cross-platform The version in ganglia-modules-linux is based on the same code, with some small enhancements (using arrays instead of string comparisons) Therefore, I'm simply going to leave it out of the core ganglia distribution - anyone who wants to use this module can still get it at http://gmod-linux.sourceforge.net/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] moving mod_multicpu out of ganglia to ganglia-modules-linux
On Mon, May 14, 2012 at 01:17:19PM +0200, Daniel Pocock wrote: The mod_multicpu code in the main ganglia repo is Linux-only, while most of the other modules are cross-platform I think it might also work for cygwin but haven't really tried lately, if that is the case though it will remove this functionality from cygwin for no big gain IMHO. Most of the python modules are linux specific though, so would guess your comment was about native modules instead. The version in ganglia-modules-linux is based on the same code, with some small enhancements (using arrays instead of string comparisons) instead of having a forked version, why not make multi-cpu portable instead? and if you think your linux version is better, why not import it instead? having a mechanism to identify which OS is supported by each module was something that was missing in the modular architecture from the start (since it was modeled after apache that doesn't have that requirement) and adding this functionality instead of hacking around the lack of it would be IMHO a better option, eventhough that would most likely require a binary incompatible change and therefore a different (at least minor) version of ganglia, which seems is something we are fond of now anyway considering I'd seen some code released as 3.4 already. Carlo -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] Trac Wiki, Bugzilla and GitHub
I spoke with Vladimir briefly on IRC and he recommends that we just move to GitHub Issues, reason being it works better with the GitHub workflow (as Alex Dean also mentioned in his email). I am okay with this, as long as we take the effort to go through bugzilla.ganglia.info and close out obsolete tickets and move all the relevant open ones to GitHub Issues. We can leave the old bugs in Bugzilla for archival purposes and in read-only mode. Another option which Vladimir suggest is just forget about the old tickets in Bugzilla and start fresh in GitHub Issues. I am leaning towards option 1 -- what do you guys think? Thanks, Bernard On Sat, May 12, 2012 at 2:12 AM, Daniel Pocock dan...@pocock.com.au wrote: On 12/05/12 00:44, Bernard Li wrote: Hi Daniel: On Fri, May 11, 2012 at 3:08 AM, Daniel Pocock dan...@pocock.com.au wrote: If I host it, it would purely be on a voluntary basis, so I would be hoping for upstream and/or Debian to be providing convenient packages and security updates. Although I am quite capable of installing it manually, time spent maintaining such an install of bugzilla would cut into time spent maintaining any other open source packages I contribute to Thanks to Ben Hartshorne, I was able to find this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638705 So yeah, bugzilla is temporarily removed from Debian. However, it's Yes, that was the same link I posted - it doesn't say temporary or permanent, it just says they need at least 2 people willing to support the package in some sense. It also suggests that the way upstream distributes the tarball makes it necessary to do a lot of patching, that deters people from maintaining a package. still available in EPEL: http://dl.fedoraproject.org/pub/epel/6/x86_64/ Is this really an issue? Yes, definitely, because if something like that is publicly accessible, it needs security updates. Debian and RHEL often put out security updates for supported packages within a matter of hours (much faster than the non-Linux platform vendor) The reason for using Debian is that I already have a VM running for reSIProcate, it could be shared for the Ganglia project, used to bootstrap releases, etc. The physical server is under a commercial hosting contract in Telehouse, one of London's most well connected data centres: http://en.wikipedia.org/wiki/Telehouse_Europe#London -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
