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
b...@biot.com
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
