Hello. The 2.2.x branch is almost finished, regarding my own refactoring objectives, so it's time to discuss a release schedule. The plan is to have a shiny 2.2.0 stable version on september.
I'm currently porting the available plugins (netdiscovery, snmpquery, and ocsdeploy). As the interface between the agent and the plugins changed, they will be usable only with an agent version >= 2.2.x, and the last one won't be usable with currently existing versions. If you want to extend current interface, that's the moment to do it. Also, we need a non-regression campaign. Basically, this just mean comparing current stable agent output with 2.2.x branch output, and *intelligently* comparing the results. This can't get automatised, as some changes are expected, in particular, many non-sense data have been removed. Also, running the test suite can be helpful. I have to create a page on the wiki about this. Last, I'd like to discuss additional issues beyond the code, and in particular several ones related to distribution. 1) we currently distribute three different self-contained distributions of the agent: - the windows version - the macos version - the so-called unix prebuilts I'm a bit concerned than none of them use the same layout, nor the same installation logic. For instance, the macos one is astonishingly ugly, with wrapper scripts all over the place, making quite difficult to stop a running daemon to test the agent interactively. As a consequence, I'd like to adopt more consistency between all of those distributions. 2) I'd like to discuss the way we distribute plugins. Some of them are dangereous (all the ones allowing to change the host they are running on), a subset of them being also utterly flawed (the ocsdeploy one, for instance). For those reason, I really think we should never bundle those plugins with the agent, and always distribute them separatly, including for the previous set of distributions (the all-in-a-single-file ones). This would also brings more consistency between the various platforms. 3) I'm interested in a windows native package, meaning a .msi file, in addition to the interactive installer for this platform. -- BOFH excuse #302: microelectronic Riemannian curved-space fault in write-only file system _______________________________________________ Fusioninventory-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fusioninventory-devel
