[From nobody Thu Jun 25 05:55:08 2020 Received: from mail-yb1-xb2d.google.com ([2607:f8b0:4864:20::b2d]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEehZ-0000vM-OI for openwrt-devel@lists.openwrt.org; Thu, 11 Apr 2019 18:45:36 +0000 Received: by mail-yb1-xb2d.google.com with SMTP id l124so2604710ybf.9 for <openwrt-devel@lists.openwrt.org>; Thu, 11 Apr 2019 11:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=olmari.fi; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hkmsgsm4t0egBffAjBQK5E1HtZnqSj5R1yrFHvQwqy8=; b=NYsPmIIBwkC6nsVcD4zerE33uwqdE7DxUtwcTzREKRZpnF0iXiTUsrCBvCI0PkjzXb 2Y1ZFT/99uUJXqnug3fwRdygO4dqx1kUn22CoM5jSMawAkxw9WDGv91p2XALfXX76GS3 EcX8ETxXTaZoCCS2K+GNUfk0/TdJDybizjiFw4cyHl66wEo7pk2dB/95zcXWOc1cS85K d+K5dukttsuXQPLxc8ojFog8EiLZxhfMrpnQJYoT3fYxmrtBQSK1hhdcgESkxXFwx53G aYU/tBJRoFAmSXo9lFavLLLtNvxhASYCl+slqQXP6VT3vO21zqfuk+2JP02yIv11juBA W2zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hkmsgsm4t0egBffAjBQK5E1HtZnqSj5R1yrFHvQwqy8=; b=hgEqpqfRUV5j0iloPse7sj+r9onVH0T131hMgbP/bZZxGKFL+Z/TsWamMC7hHTuNmL gLOTdHHTiTP3tZqAgJHP7OIEHxM4M4K6xldyMeXKub6es11IBGe6S4SXZR0ShJpuYmuH d/Goi6qv1D6Wb6qX1J+Zn4OsSL/TiroKdkw9JuHVWPQNKL8KNxhN4Quw+t51aBSmzykx 22sA3sBKzAle5m9d+UMDNfGHV9N5gomg0Gulo3xLtNQh5n9kNhU6+xc611Eceql8TgcE juZ6hTmc0xbu7aiA6Cj96C4uIm4YNw6eeHNfDBH/rlE+CdmzbfZE1cjnBGDXhIUNEZYT GBbw== X-Gm-Message-State: APjAAAVDXOeQhYjha/2UTdDAgGMQ0bWoP+v9S2QbBFQfKc4njo3VRk0T hFQx3OVzG0/VKnQOdJKzTFBl1aN1g7al4etPTSa9lQ== X-Google-Smtp-Source: APXvYqz40dXPb3ZaHzXPP4mbFeYBELTUO/ZYoXC8dhv15T1/JoWwGdkUB0cVitMbd2MPTTVEXxtVfZDB0vnxxtsGSzg= X-Received: by 2002:a25:50c1:: with SMTP id e184mr42572049ybb.125.1555008330919; Thu, 11 Apr 2019 11:45:30 -0700 (PDT) MIME-Version: 1.0 References: <20190411125618.GD61929@meh.true.cz> <63d36a09-26fe-e0ff-8d60-3f799645f61c@wagsky.com> In-Reply-To: <63d36a09-26fe-e0ff-8d60-3f799645f61c@wagsky.com> From: Sami Olmari <sami@olmari.fi> Date: Thu, 11 Apr 2019 21:45:19 +0300 Message-ID: <CAENOc+y=PH8nFE4Yo9masOqQPk8HjLVtX9PPS2+tkDcJ2uO7Bg@mail.gmail.com> Subject: Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200 To: Jeff <jeff@wagsky.com> Cc: =?UTF-8?Q?Petr_=C5=A0tetiar?= <ynezz@true.cz>, wellnw <guilin.wang@gl-inet.com>, openwrt-devel <openwrt-devel@lists.openwrt.org>, "Kevin 'ldir' Darbyshire-Bryant" <ldir@darbyshire-bryant.me.uk> Content-Type: multipart/alternative; boundary="00000000000030053305864597f8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190411_114534_404661_11CD88BD X-CRM114-Status: GOOD ( 17.71 ) X-Spam-Score: -0.2 (/) X-Spam-Report: SpamAssassin version 3.4.2 on bombadil.infradead.org summary: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:b2d listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain --00000000000030053305864597f8 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 11, 2019 at 5:31 PM Jeff <jeff@wagsky.com> wrote: > Wow, I would have thought a simple > > "Thank you for your submission. We appreciate your commercial concerns. > We look forward to your future submissions on the ath79 platform." > > would have been more than enough. > > GL.iNet is one of the few OEMs that commercially benefit from OpenWrt > development that take the time to try to return patches and enhancements > directly to the project. "Don't waste our time" comes through loud and > clear. If I were an OEM, why should I bother submitting patches? There > is real opportunity cost associated with doing so, and not very much > tangible benefit compared to maintaining their own "private" branch. > > That the ath79 target on Linux 4.14 doesn't support NAND makes it > challenging for a manufacturer to simply switch over their entire code > development. Yes, patches for ath79 on Linux 4.19 dropped a week or two > ago. However, a reputable manufacturer isn't going to ship product on an > untested code line. So far I have seen that batman-adv won't even > compile under ath79/4.19. Also, while the framework is supposedly > present for NAND in Linux 4.19, as far as I know no devices have been > demonstrated to be able to use it under OpenWrt. Not that I expect those > things to magically happen, but they do make it challenging for a > responsible OEM to switch over as easily as a hobbyist. > > > Jeff > For what it's worth to say from "back here from the side", I don't think the "waste our time" was meant as bad as it did indeed sounded... The thing still is that AR71xx target is planned to be obsoleted after very next OpenWrt stable version, so it doesn't make that much sense figuring out anything major for that target. Unfortunately, like Jeff pointed out too, ATH79 isn't 100% working in all areas, but that can only change with developing... There is also "clash" of new codebase and MFG releasing mature enough stuff. That is something that allways will exist. All I can say to that is that an device MFG builds and does whatever they deem to be best practice (to them), if it is sticking to codebase that is on phase of being obsolete, they can do so. It will work for current devices and even new devices appearing in near-future, but it will not be long-term solution... Also one should think that having new codebase that is deemed to be overally better, everyone should focus on developing that instead of burden of figuring out similar stuff for 2 codebases... These kind of transitions are never painless... Best regards, -- Sami Olmari --00000000000030053305864597f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">On Thu, Apr 11, 2019 at 5:31 PM Jeff <= <a href=3D"mailto:jeff@wagsky.com">jeff@wagsky.com</a>> wrote:<br></div>= <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= "> Wow, I would have thought a simple<br> <br> "Thank you for your submission. We appreciate your commercial concerns= . <br> We look forward to your future submissions on the ath79 platform."<br> <br> would have been more than enough.<br> <br> GL.iNet is one of the few OEMs that commercially benefit from OpenWrt <br> development that take the time to try to return patches and enhancements <b= r> directly to the project. "Don't waste our time" comes through= loud and <br> clear. If I were an OEM, why should I bother submitting patches? There <br> is real opportunity cost associated with doing so, and not very much <br> tangible benefit compared to maintaining their own "private" bran= ch.<br> <br> That the ath79 target on Linux 4.14 doesn't support NAND makes it <br> challenging for a manufacturer to simply switch over their entire code <br> development. Yes, patches for ath79 on Linux 4.19 dropped a week or two <br= > ago. However, a reputable manufacturer isn't going to ship product on a= n <br> untested code line. So far I have seen that batman-adv won't even <br> compile under ath79/4.19. Also, while the framework is supposedly <br> present for NAND in Linux 4.19, as far as I know no devices have been <br> demonstrated to be able to use it under OpenWrt. Not that I expect those <b= r> things to magically happen, but they do make it challenging for a <br> responsible OEM to switch over as easily as a hobbyist.<br> <br> <br> Jeff<br></blockquote><div><br></div><div>For what it's worth to say fro= m "back here from the side", I don't think the "waste ou= r time" was meant as bad as it did indeed sounded... The thing still i= s that AR71xx target is planned to be obsoleted after very next OpenWrt sta= ble version, so it doesn't make that much sense figuring out anything m= ajor for that target.</div><div><br></div><div>Unfortunately, like Jeff poi= nted out too, ATH79 isn't 100% working in all areas, but that can only = change with developing...</div><div><br></div><div>There is also "clas= h" of new codebase and MFG releasing mature enough stuff. That is some= thing that allways will exist. All I can say to that is that an device MFG = builds and does whatever they deem to be best practice (to them), if it is = sticking to codebase that is on phase of being obsolete, they can do so. It= will work for current devices and even new devices appearing in near-futur= e, but it will not be long-term solution...</div><div><br></div><div>Also o= ne should think that having new codebase that is deemed to be overally bett= er, everyone should focus on developing that instead of burden of figuring = out similar stuff for 2 codebases...</div><div><br></div><div>These kind of= transitions are never painless...</div><div><br></div><div>Best regards,<b= r></div><div>-- <br></div><div>=C2=A0Sami Olmari<br></div></div></div> --00000000000030053305864597f8-- ]