project goals

Vittorio G (VittGam) openwrt at vittgam.net
Wed May 4 14:49:36 PDT 2016


Hi,

On 04/05/2016 22:30:40 CEST, Bert Vermeulen wrote:
> Hi all,
>
> Very happy to see this project reboot happening. An acknowledgement of the issues facing OpenWRT was long overdue. I'd like some clarity on some things that aren't explicitly mentioned in the stated goals, however.
>
> First off, is the SVN nonsense definitely gone now? Will the LEDE project be all-git? I assume yes, but would really like to see this confirmed.
>
> Secondly, the major technical problem OpenWRT faces IMHO has always been the ever-increasing technical debt. In this case this is carried in the form of a *gigantic* number of patches. There are patches for lots of packages, and even the kernel and U-boot. I count over 4700 of them in OpenWRT, 3842 in LEDE right now.
>
> This is the sort of thing you expect to see in the internal repo of a company not yet convinced of the benefits of upstreaming; to see this carried in an open source project is downright shocking.
>
> I propose to make it an official goal to carry no patches at all; everything should be upstreamed or dropped. That is the only policy that makes any sense at all.
>
> Comments, opinions?

I personally don't think "upstream or drop" would be a good thing to do.

Regarding package patches, I think that some are just specific to make the package work in an embedded system, and maybe upstream can possibly just not be interested in this sometimes.

Regarding U-Boot patches I don't think it's not OpenWrt's fault. For example, many Atheros devices use an ancient trunk of U-Boot (1.1.4) with many patches from Atheros or router vendors applied to it. Upstream might simply not be interested in these patches.

Regarding kernel patches instead, the OpenWrt trunk is/was usually used also as a test-bed for some changes that will eventually go upstream at some point, and many actually went in the mainline kernel.

Upstreaming kernel patches is usually a long process, and is usually meant for finished and polished things, at least to some extent. So you can't really experiment with things anymore once it's upstreamed. You want to make sure that every rough edge is solved before upstreaming something.

Also, upstreaming patches requires some effort/time, and maybe that was not always present in OpenWrt, I don't know.

By the way I'm not saying either that trunk is or should be the far-west of wild patches... ;)

So, yes, when something is stable enough, and upstream is interested or otherwise upstreaming is feasible, then it should be upstreamed. But I believe this is already what was happening with OpenWrt...

But, no, when something still needs to be fully tested I think it should not be upstreamed yet, and that the OpenWrt/LEDE trunk might just the right place for it.

Cheers,
Vittorio



More information about the Lede-dev mailing list