I saw your first commit about this.

Have you some time to explain how concretely you will manage packs and modules ?

Where plugins (scripts) would be stored ? 
Many time, a pack comes with its own plugin
Should we work with the plugin separately from the pack it belongs to ?
Can we include the plugin into the pack ?
If yes, what about plugin that needs install script (for dependancies ...)
Packs will changedir from etc ?
How to manage custom packs/modules without overwriting existing packs/modules ? (so that we don't have to fear a module/packs update) ?
How to upgrade shinken from previous version (1.2.4 or 1.4 to 1.6) ?

Last but not least, how can we help with this ?
 Will you create multiple small task that everyone can contribute to ?
For example :
  To achieve this first part, here are 5 small "git hub issue" to be solved ?
   Then we can attack the second part that contains 10 small task ...
Or you will code all and ask for tests ?

I know, it's too many questions :s

2013/5/31 nap <naparuba@gmail.com>

On Fri, May 31, 2013 at 2:03 PM, Jean-Michel Collongette <jean.mich.c@gmail.com> wrote:

I agree to separe the packs from the shinken core.

This way could be easy to manage enhancement and upgrade of single packs instead of wall of them currently.



That's also one important thing for external packs and modules : they can have their own release schedule. Some modules got lot and lot enhancements, but are only "release" with the full stack. It's quite the same with modules.


Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
Shinken-devel mailing list