[OpenWrt-Devel] [PATCH 1/1] ramips: remove RB750GR3 support

[Sylwester Petela]

W dniu 21.07.2018 o 10:43, Thibaut pisze:
>
>> Le 21 juil. 2018 à 10:17, John Crispin <john at phrozen.org> a écrit :
>>
>>
>>
>> On 21/07/18 09:44, Thibaut wrote:
>>>> Le 21 juil. 2018 à 09:24, John Crispin <john at phrozen.org> a écrit :
>>>>
>>>>
>>>>
>>>> On 19/07/18 20:08, Thibaut wrote:
>>>>>> On 19 Jul 2018, at 19:52, Mathias Kresin <dev at kresin.me> wrote:
>>>>>>
>>>>>> 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE <hacks at slashdirt.org>:
>>>>>>> faf94d926e2810f895f2a98d4a49ee2fe8f673e8 added "support" for a hacked
>>>>>>> device where the original boot loader (routerboot) has been replaced
>>>>>>> by u-boot.
>>>>>>>
>>>>>>> Support for this device with stock bootloader is possible (as evidenced
>>>>>>> by support for the RBM33G), and conflicts with this code.
>>>>>>>
>>>>>>> Remove code before release.
>>>>>>>
>>>>>>> Signed-off-by: Thibaut VARÈNE <hacks at slashdirt.org>
>>>>>> FYI, I already NAK'ed the very same patch on github.
>>>>>>
>>>>>> I do agree that it can be done better by not requiring the replacement
>>>>>> of the bootloader. Nevertheless, support for this board is already
>>>>>> shipped since LEDE-17.01 and I don't agree to drop support for a board
>>>>>> without providing an alternative/fixed/better image.
>>>>> Just to clarify: this is not “support”. This is a user created custom hack that applies only to their modified board.
>>>>>
>>>>> T.
>>>>> _______________________________________________
>>>>> openwrt-devel mailing list
>>>>> openwrt-devel at lists.openwrt.org
>>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>> Hi,
>>>> I agree that proper support for none modified boards is far better and I am always for having such support in tree. what i am failing to understand here is why it is so important to remove this support or none-support patch from the tree ? in general our stance was that if there is at least one user we'll try to carry the functionality as long as we can. So why not remove this when a better replacement is in place ?
>>> Because there will be no replacement and I certainly don’t want to confuse the end users into thinking there will be one.
>>>
>>> I don’t know yet another way to say this more clearly: this patch doesn’t “drop support”: support was _never there_. There will be no “replacement”: there is no upgrade path.
>>>
>>> What this patch does is dropping bad code. What there will be is proper, correct NEW support for the hardware this code /pretends/ to offer support for but doesn’t.
>>>
>>> At the end of the day the device covered by this code is a /different/ device than the one support will be provided for. It’s A Frankendevice, that by the way doesn’t even pass the “hardware available?” question. The installation instructions on the wiki do not even provision a way to revert the hack.
>>>
>>> On a side note, if it’s a policy to support every user hack and bastardized hardware for which there is only one user _in tree_, then we have a fundamental difference in opinion and I’m afraid openwrt is then inflicting on itself a maintenance nightmare it can’t afford.
>>>
>>> My 2c,
>>> T
>> well, that certainly killed the discussion ....
> Trying hard to explain my reasoning kills the discussion? I’m frankly baffled.
What John and others probably meant is that killing device support 
(replacing u-boot IMHO isn't "hardware mod" as You described(look at 
lantiq devices)) isn't best approach, instead if You have hardware in 
discussion You can help develop better support for questioned device and 
REPLACE/FIX it's implementation in OpenWRT.

Every device hack/introduction to OpenWRT has to began somewhere.
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel