OpenWrt-base for next minor-release

[SvenRoederer]

@bobster-galore once mentioned that we should consider using OpenWrt 19.x as base for the next minor-release (Hedy-1.1.x).

That idea is based on:

• OpenWrt 18.06.1 is out already, but we a far from a point we can think of a release
• building 1.0.2 on OpenWrt 18.06 will bring us again in the situation, that we have to run behind the features that that the OpenWrt-guys do for master
• what do we loose when skipping OpenWrt 18.06 and choose a well working OpenWrt-master?

[SvenRoederer]

for some reason the master seems to have problems with at least the Archer C7v4, whereas the Sam0815_experimental branch (based on OpenWrt master) seems to work. see https://lists.berlin.freifunk.net/pipermail/berlin/2018-August/038213.html - let's take this as a vote for OpenWrt-master

[bobster-galore]

Yes pls, I think there is no worth in using outdated software only for historical reasons.

[booo]

When we started to develop this firmware one of our goals was a stable firmware. Therefore we chose a stable openwrt release as the foundation of the firmware. If we start using the master branch or some unpublished release we compromise the idea of a stable firmware.

[SvenRoederer]

As mentioned before we are far away from a 1.1.x release. When we keep our current development-speed, we might have our code ready for a relase, when OpenWrt 19.x or some of its rc-versions has been published.
By skipping OpenWrt-18 and going from lede-17.x to OpenWrt-19.x we avoid running behind the OpenWrt-release and even stay on a published stable openwrt release as the foundation

[bobster-galore]

I understand the idea of stable firmware. On the other hand it seems to me that development of routers speeded up compared to early freifunk times, when the same router model ran for a longer time.

I think it's desirable being also able to support recent routers (e.g.archer c7 v4, cpe210v2, wr1043v5). What about developing on OpenWrt-19.x and if we find we are ready to release we check if it's already stable or backport?
@torte71 @pmelange how u mean?

[booo]

I'm ok with using 19.x for one of the next releases.

What are the open issues for a next release? Why a we so far away from a next release? Is there a ticket for a next release?

[bobster-galore]

Are the next steps?
1.0.2 sw-update Lede, DNS-Server out #551
1.0.3 switch vpn-tunnels vpn03, community-tunnel, ipredator, in-berlin
1.1.0 recent openwrt, new routers,
do u agree?

[pmelange]

I think that having our firmware as stable as possible is important. If people want to have support for their recent routers, they can be brave and use a development branch.

for #551, we still need a new DNS to add to the profiles.

I would add the openvpn changes, iptables (ffuplink), and mac addr for ffuplink to the next minor release.

It would also be great if the community-tunnel (via tunneldigger) and bbbdigger packages would be in the next minor release.

[pmelange]

Shall we have a developers meeting some time? Maybe not on a Wednesday? I could imagine doing it at the Scherer8, but I'm open to other suggestions.

[bobster-galore]

On a Spandau meeting we discussed the point and agreed on developing on latest firmware.

[pmelange]

Developing is not the same as releasing. What about the releases? Did the Spandau meeting agree to making releases based on the OpenWrt master branch?

[booo]

What means "developing on latest firmware"? Please be more precise in your writing.

We will develop on a stable openwrt release or release candidate and we will create a release based on a stable openwrt release. I don't we have to discuss this further.

[bobster-galore]

We will cross the bridge when we meet it.

[SvenRoederer]

As per http://lists.infradead.org/pipermail/openwrt-devel/2018-September/014060.html it's planned to branch of OpenWrt 19.01 in December 2018.
As this in two months I don't see any point in doing a release based on OpenWrt 18.06

[booo]

If the master branch is stable we should push for a release before the new year and plan another release for the new year.

[pmelange]

I also think it makes sense to get a release done based on the latest stable openwrt 18 release.

We should plan a release based on openwrt 19 when it's actually ready. December can easily become March.

[SvenRoederer]

we should plan at least when the rc1 gets branched. maybe then we a close to a release then it's final.

[SvenRoederer]

as per http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015941.html OpenWrt19.03 will come, probably it will be 19.04.
Once more I suggest to set our master to OpenWrt master and then follow the 19.03-branch. There are still so many issues in our firmware, that the branch will be ready before us.

[pmelange]

I still think it makes sense to wait until 19.04 is released.

In http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015982.html there are some bug which have a big influence on Freifunk.

• TL-WDR4900 is currently broken
  [RFC] mpc85xx: generic: Broken image of TL-WDR4900 openwrt/openwrt#1773 (This is the workhorse of the backbone)
• Mesh is broken using ath10k-ct?
  https://bugs.openwrt.org/index.php?do=details&task_id=2123
  (this is an important feature of the next planned release)

If these bugs get fixed before the release, then I would be ready to move to the 19.x branch.

[SvenRoederer]

* Mesh is broken using ath10k-ct?
  https://bugs.openwrt.org/index.php?do=details&task_id=2123
  (this is an important feature of the next planned release)

I can not confirm that. I've running some nodes (mixed setup of Hedy-1.0.2, Hedy-1.0.3-alpha and dev-daily) here without problems.

[SvenRoederer]

• Mesh is broken using ath10k-ct?

oh, just seen, that this should be ath10k specific ... that's some kind of hardware I don't have on hand.

[SvenRoederer]

• TL-WDR4900 is currently broken
  openwrt/openwrt#1773 (This is the workhorse of the backbone)

This was recently fixed / work around: openwrt/openwrt@84b1257

[SvenRoederer]

The WDR4900 support became a separate issue: #680

[pmelange]

The WDR4900 issue has been resolved with commit openwrt/openwrt@c4fdd49

Is there any info about the "Mesh is broken using ath10k-ct" issue?

[pmelange]

I have just done a test with daily/upstream-master (8ace7a4)

iw list on an ath10k device still gives the following results (5Ghz):

	valid interface combinations:
		 * #{ managed, P2P-client } <= 16, #{ P2P-GO } <= 3, #{ AP } <= 16, #{ IBSS } <= 1,
		   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }

It is still missing mesh point

for comparison, on a non-ath10k device it looks like this:

	valid interface combinations:
		 * #{ IBSS } <= 1, #{ managed, AP, mesh point } <= 8,
		   total <= 8, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }

[SvenRoederer]

Please see #696 for the ath10k-mesh issue.

[SvenRoederer]

just realized by reading http://lists.infradead.org/pipermail/openwrt-devel/2019-June/017590.html that OpenWrt-19.07 has been branched recently. Branch-point is openwrt/openwrt@c53f62b

[pmelange]

just realized by reading http://lists.infradead.org/pipermail/openwrt-devel/2019-June/017590.html that OpenWrt-19.07 has been branched recently. Branch-point is openwrt/openwrt@c53f62b

That is great news. However, I heard that I shouldn't expect a release until Sept. So, for the time being, I think that we should stick with the latest patches on the 18.06 branch for the next release. When 19.x finally arrives, I hope we can then again push out a new release.

[SvenRoederer]

there is a Gluon-PR to discuss on switching to 19.07: freifunk-gluon/gluon#1791

[SvenRoederer]

we have an openwrt-19.07-rc1 ready (openwrt/openwrt#2507 (comment))

[SvenRoederer]

master-branch has been switched to OpenWrt-19.07 some days ago, So I like to close this.
If anyone likes to discuss on going for OpwnWrt-20.02, please reopen.