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