Source tree reorganization

[aquette]

The source tree has become a big incoherence over the years.
This has been discussed in length several times on the mailing list.

There are both reorganization, simplification and optimization to be done:

• conf
• data
• docs
• include
• lib
• m4
• packaging
• scripts
  • tools
• src
  • common
  • client
    • cgi
    • nutclient
  • config
  • drivers (subdirs for big drivers)
    • ipmi
    • snmp
    • usb
  • scanner
  • server (upsd or nutd)
• tests

Other considerations:

• packaging/ under scripts/
• most common/ things are now (or should be) in lib/ in fact

to be completed...

[clepple]

One other thing we should also consider is that the core of NUT is still GPL v2+, and we now have some GPL v3 files (mostly PyNUT-related). The GPL v3 files really should be in a separate repository, IMHO.

[aquette]

@clepple : what's the rationale behind a separate repository?
We already provide visibility in COPYING, in a manifest-like style, and the various licensed-code is already separated in directories (scripts/python/, scripts/perl). And this is not incompatible licenses.
So splitting the archive will just make my release-mgr life harder, but I fail to see the actual value for users ;)

on the other hand, having separate repos. per bindings and sub-projects makes sense, and is already what we did (for other reasons) with jNUT and the website and ddl. This makes the main archive lighter and more coherent (considering that different licenses are tied to sub-projects, not the core).
we could extract pyNut (and soon have pyNut2) and the Perl binding. I don't see anything else on my side.

that brings me some more ideas and need for thinking, with NUT 3.0 in mind, and the upcoming c++ code, new drivers and general rework...

[clepple]

Licensing is not the only argument for a separate repository. Since the PyNUT and jNUT bindings are not built from the NUT sources, they don't need to be in the same tree, or released at the same time. I don't think that makes release management harder, just different. But I'll let you be the judge of that.

Actual value to users: agreed, it isn't direct. I was assuming some distributions would be more pedantic about the license of NUT as a whole, but I guess that isn't a problem. I had not seen the actual text of the Debian copyright file, and you're right, it is specified per-directory.

[clepple]

Speaking of value to end users ;-) what are you hoping to accomplish with C++? I keep hearing bits and pieces about this, and I am not very optimistic, given the state of the nut-scanner code. I have not seen C++ solve more problems than it creates.

[aquette]

@clepple : also a separate discussion, but quickly: c++ is more for devs than users. Though, by side effect, this will obviously benefit to the user, the point is to have better code (and coding) for some news components (new drivers or rewrites) were we could do better with OO. Not a holy grail or golden hammer though, but just a way to push what we've learned over years.
on nut-scanner, it's not c++ at all. It was only the first version of an old idea. But there also, we learned ( hence #14 ). No worries, there will be some specs soon by @balooloo and me to share and show the intent.

[clepple]

moving the C++ discussion to nut-upsdev