[Fusioninventory-devel] 2.2.x schedule

[Guillaume Rousse]

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