project goals

[David Lang]

On Wed, 4 May 2016, Vittorio G (VittGam) wrote:

> 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.

Some patches are going to be something needed to make a particular model work, 
but upstream is not going to be interested in accepting the patches.

That being said, I think that there is probably a lot of room for improvement if 
there are currently ~4000 patches to upstream. Does anyone have a nice report 
that can show how these 4000 break down across the different upstreams?

If it's easy enough to see what is what, it may be that outsiders can look 
through them and do some triage

1. are they cosmetic changes

2. how invasive is the change

3. is the change well documented

4. is the change needed to make something work

5. how long has openwrt been carrying the patch

With a little bit of sorting, I think that there are probably a bunch of patches 
that we will find can be dropped as 'not worth bothering with', and a bunch that 
fall into the category of 'small patches needed to make something work' that 
could be pushed upstream fairly easily.

Just getting the counts down will ease introducing new versions, reducing the 
load on developers so they can produce more patches ;-)


But I do think a push to get as much as possible upstream will help. And it will 
help not juse LEDE/OpenWRT but also every other project that's targeting this 
space. If we can get them to do the same thing, the workload will go down for 
everyone.

David Lang