project goals

[Hauke Mehrtens]

On 05/05/2016 10:03 PM, Bert Vermeulen wrote:
> On 05/05/2016 04:09 PM, Hauke Mehrtens wrote:
>> I think we should encourage everyone to upstream the patches, I think in
>> one of the statics I saw that OpenWrt ranked 3. or 4. in contribution to
>> the kernel among the Linux distributions before Canonical. ;-)
> 
> Encourage is just a word. Nobody in OpenWrt ever discouraged
> upstreaming, I should think. But without a "no non-upstreamable patches"
> policy, you will inevitably build up a technical debt.
> 
> I had a look at the OpenWrt repo over the last two years. Here's what
> the lack of such a policy did for openWrt:
> 
> - versioned kernel patches: between 1426 and 2807
> - versioned kernel patches, top kernel only: 1204 -> 977
> - non-versioned kernel patches: 177 -> 316
> - non-kernel package patches: 381 -> 514
> - tools patches: 95 -> 114
> - toolchain: 142 -> 79 (halved two weeks ago)

How did you measure these values? When you look at kernel patches it
probably only makes sense to look at the most recent kernel version
supported to not count the same patch double only because it is applied
to different kernel versions. Also this contains some backports for more
recent versions like the musl support for gcc was added in gcc and we
wanted to use it before.

> The conclusion is equally obvious and terrible: this is not going to
> resolve itself.
> 
> The number of patches being upstreamed from OpenWrt to the mainline
> kernel is in NO WAY making a dent in the patches carried along in this
> repo. Making things considerably worse is the fact that many patches are
> in no shape to be accepted by mainline -- using outdated or non-existent
> APIs, or just of shoddy quality. Upstreaming such things often means
> rewriting them completely, as I've had the misfortune to notice.

This also depends on the developer. When you look at the Broadcom
brcm47xx and bcm53xx target for example most of the mainline kernel code
was done by OpenWrt developers and first added to OpenWrt and then
upstreamed.

> Think about that for a minute: stale internal API, shoddy code, stuck in
> internal repo because used in shipping product. That is the definition
> of technical debt.
> 
> How can you possible defend this status quo?
> 
> 
>> Only allowing upstream patches also conflicts with the goal to be more
>> stable and not always use the most recent kernel which introduces new
>> problems again.
>>
>> Some kernel patches are also directly extracted from some other
>> repositories or from some vendors. The raspberry pi patches for example
>> are exported from some other repository.
> 
> Those are both very poor excuses. This project does not use the most
> recent mainline kernel because it has a thousand patches that need
> porting, not because it "introduces new problems". The problem is right
> here, nowhere else.

Makeing a target compile and boot with a more recent kernel is normally
not a big problem, but there are then some new bugs introduced by the
new kernel version and that causes some problems.

Hauke