project goals

Bert Vermeulen bert at biot.com
Thu May 5 13:03:22 PDT 2016


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)

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.

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.


-- 
Bert Vermeulen
bert at biot.com



More information about the Lede-dev mailing list