Nut upsdev - Jun 2011 - 2.8.0 roadmap

Dear NUT developers and contributors,

time has come to shed more light on 2.8.0 roadmap!

Ubuntu Developer Summit attendance has helped to clarify things.
several of 2.8.0 tasks are detailed here:
https://wiki.ubuntu.com/ServerOneiricInfraPower

I'm conscious that our development infrastructure (Alioth) is not that
suitable to track roadmaps, "Agile" specs and developments, as we do
in NUT.
Charles and I are still investigating possible improvements.


as for the 2.8.0 roadmap itself, here is the overall plan:

1) NUT schedule is mapped on the next Ubuntu release (11.10, aka Oneiric
Ocelot), to be available in it:
https://wiki.ubuntu.com/OneiricReleaseSchedule

this means that:
- once released, NUT packages have to be updated in Debian, and then sync'ed
in Ubuntu. which needs a bit more time,
- the above has to happen between August 25th (Beta freeze) and September
29th (Final freeze)

but this doesn't mean that other distro / OS, or users needs in general,
won't be considered!
it's simply a main target.

2) the targeted features list is:

priority 1)
  * Mozilla NSS support:
    I've got to go again through this, but code is done, tested (including
regression) and should be ready for merge (congrats again to Emilien Kia and
thanks to Eaton)
    I hope Charles will be able to handle the merge ;)

  * nut-scanner:
    Fred Bohe is currently working on this, and has already made good
progress.
    a first version will probably be merged in the trunk next week ; from
there, improvements will happen on the trunk
    the task should be completed by the end of June (another thanks to
Eaton)

  * configuration: I'm not yet sure about the exact content of this task!
     pyNutConfig class + CLI pynut-config (or simply nut-config), with an
augeas wrapper first and maybe simple fallback with no deps
     optionally integrate in NUT-Monitor with a GUI
     David Goncalves will maybe help on this one

  * nut-ipmi driver step 1
    only include power supply unit (PSU) support
    I'm still doing some investigation, but already have few things (m4
macro and very initial driver)
    I should be able to commit something within the next couple of weeks

  * jNUT Java binding
    the exact content of this task is still to be defined, but this should
include native client access and NSS support,
    the following will be considered with a lower priority:
      - device discovery (JNI using libnut-scanner),
      - configuration (using Augeas)
      - mDNS discovery
    I'm currently checking resources staffing with Eaton

  * PowerChain step 1
    as described in the above ServerOneiricInfraPower link, the idea is to
be able to link powerflow, and consider the whole. power chain, and not
anymore the UPS only. the nut-ipmi driver is a dependency of the task
    step 1 adds:
      - device.parent in nut-names,
      - support in drivers (parameters in main.c->storeval())
      - support upsc for "-P PowerChain"
    I've already started a few things, and will get back soon for the RFC

  * NUT generalization, step 1
    - more generic nut names (ie move from ups.* to device.* in
nut-names.txt)
    - move existing ups.{model,mfr,...} to device.* in drivers
    - move ups.status to device.status
    - with compat mapping counterparts (device.* also to ups.* if
(device.type == ups))

  * standard flow of bug-fixes and stagging improvements...

priority 2 (best effort)
  * powerchain step 2: support in upsmon
  * Windows port integration: if possible, need step refactoring /
enhancement / more testing
  * better Mac OS X integration (including StartupItem initscript, .pmdoc
packaging script and ?)


I realize that this is ambitious, as Arjen noted, but not impossible and the
progress is already good.
we also have priority 2 which are best effort. so we can still postponed
these a bit more, if needed.
we're finally gaining more support from Eaton, hopefully in a stable way,
which will be determinant.

I will get back to you soon with RFCs and progress update on the above.
Feedback, comments, help and testing are welcome, as always.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110611/12d28598/attachment-0001.html>

On Jun 11, 2011, at 3:53 PM, Arnaud Quette wrote:
>   * jNUT Java binding
>     the exact content of this task is still to be defined, but this  
> should include native client access and NSS support,
>     the following will be considered with a lower priority:
>       - device discovery (JNI using libnut-scanner),
>       - configuration (using Augeas)
>       - mDNS discovery
>     I'm currently checking resources staffing with Eaton
I'm not a huge fan of Java to begin with, but if I had to interface a  
Java tool with NUT, I wouldn't want the hassle of native bindings  
(i.e. JNI) unless it was absolutely necessary. Most of the NUT  
protocol should be easily implementable in pure Java (including SSL).

I agree that the "lower priority" items might be more easily  
implemented with JNI.