Hi Adrian,
On 27.01.2020 19:35, Adrian Schmutzler wrote:
Just a quick one:
> So, no matter what we do, there is no easy way forward.
We could remove all ar71xx -> ath79 migration helper scripts, ar71xx
board names from supported devices lists in ath79 images and make the
target a brand new, without any concerns about soon-to-be obsolete ar71xx ;)
At the moment, I'm actually mostly inclined towards this solution.
I'm afraid it's a bit late for that as 19.07 is already out and it
supports (at least partially) ar71xx -> ath79 migration path/s.
Wouldn't that look unprofessional? Am I overreacting here?
However, for me personally SUPPORTED_DEVICES was always more a "don't brick
entirely" flag, so I never expected it to ensure 100 % config compatibility. More
like preventing me from flashing ubnt,unifi image onto tplink,wdr-4300-v1. This
impression might have been wrong, though.
I think device to image matching was the main reason behind the idea.
IIRC, mismatched image doesn't prevent you against upgrading with
preserved settings.
But as mentioned by Ansuel, there are other incompatible switches to come (and some are
already waiting), and unless we want to create new targets or rename devices in these cases,
we have to think about different "levels" of compatibility anyway beyond
ar71xx->ath79.
I believe ar71xx -> ath79 is a special case here. First of all, that's a
new DTS-enabled target and it was suppose to _replace_ ar71xx but 19.07
went out with both of them and I'm pretty sure there are users who got
confused with that (some devices are supported only in one of the
targets, some in both, some with seamless migration possible). On the
other hand, when ar71xx gets abandoned, we (as a project) should make it
clear if ath79 is a replacement (thus providing seamless upgrade from
ar71xx) or a new target, without any relationship with ar71xx (thus a
clean sysupgrade is required). Keeping anything in between would just
confuse people.
DSA is slightly different topic as it will touch many different targets
(also ath79, think about qca8k) so probably a project-wide solution
would be required.
--
Cheers,
Piotr
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
