luci-app-olsrd2: add html table for all LAN prefixes

[stargieg]

Maintainer: patrick@lunatiki.de @stargieg Compile tested: mips_24kc, arm_cortex-a9_vfpv3-d16, i386_pentium4, x86_64, i386_pentium-mmx, mipsel_24kc Run tested: Firefox, Safari

Description: add html table for all LAN prefixes instead of a list with the one/first prefix

Signed-off-by: Patrick Grimm patrick@lunatiki.de

[BKPepe]

Wouldn't it be better if we move this package to LuCI repository, where are all the LuCI packages?

[Akira25]

This might be a matter of taste. As we already have a specialised package feed for routing, I would prefer to have all routing related stuff at the routing feed. That way, people who might want to join development in rounting deamons and its apps, don't need to have the not-trivial additional knowledge on the whole OpenWrt project structure and that the related code is in another repository.

Additionally, there are three luci-apps in this feed already:

• luci-app-bmx6
• luci-app-cjdns
• luci-app-olsrd2

[BKPepe]

Well, all LuCI packages should be together. If you have LuCI, then you are dowloading it from LuCI feed, so that's a different repository. Even if you don't have LuCI packages in the packages repository.

Benefits to have these LuCI packages in one repository:

• They will be maintained , there.

  • Code changes will be reviewed by someone who is developing it and takes care of it
  • It means that anyone interested in LuCI can improve it
  • There are many more members with write permissions than here.
  • Missing treewide commits and changes
  • Eg. converting to JavaScript

  And many other changes.

  You don't expect that if you are installing luci packages by hand that they are getting downloaded from routing repository. That's just confusing.

[Akira25]

I agree on the points with the treewide commits, but from my experience I doubt, that those luci-packages will be maintained better in the luci feed.

Anyway, We should discuss this in an issue and not in this PR. I would really like to merge this PR to finally get progress on this topic. We can safely move the packages later with another PR.

[BKPepe]

from my experience I doubt, that those luci-packages will be maintained better in the luci feed.

If you are saying this, I wonder where there would be, according to you, a better place, where LuCI packages should be maintained better than in LuCI feed? When it is the place, where all the LuCI packages should be there. They should provide rules and standards for LuCI extensions.

Because otherwise the situation will happen that anyone can do what it is necessary and bring back the odds, which was removed and we are adding it back as it happened in https://github.com/openwrt/routing/pull/937 as you can see nobody stepped it to review it here. I've just done a quick look up and that PR and found some things we should address promptly.

What we are doing now is merging things that are not properly reviewed and we should avoid that as we would not be able to maintain quality and that the things are doing what they should instead overwrite defaults.