[Tinkerphones] Librem 5

[H. Nikolaus Schaller]

> Am 13.02.2021 um 22:42 schrieb David Boddie <david at boddie.org.uk>:
> 
> On Sat, 13 Feb 2021 20:28:01 +0100 Dr. Michael Lauer wrote:
> 
>> When I was younger, I could understand the ?fixation? on getting things into
>> mainline ? now, with more years on my back, I believe things would have
>> turned out differently if we were to follow the path of most commercial
>> developers ? which is, freezing the kernel at one point of time to allow
>> the rest of the folks to move forward without a moving target.
>> 
>> Later on, perhaps, submit stuff upstream, jump to another mainline kernel
>> (if necessary), rinse and repeat.
> 
> I agree. The focus on mainlining everything is above and beyond what the
> license requires.

Indeed the wish for upstreaming is not triggered by license but by practical needs.

One factor is that the more code is not part of mainline the more resources
are needed to maintain these non-mainline parts and e.g. take care of memory
leaks, security flaws etc. If they are mainline, the whole community takes
care of this and this saves resources of the project.

> 
> It's great if someone can check out the latest kernel and build it for a
> device, but some patches are never going to get upstream. Also, if your users
> need additional stuff to get a working device, having a buildable mainline
> kernel is of limited use.
> 
> Upstreaming everything is also an overhead that most projects can't afford
> unless you want to tie your features to the release schedules of your
> dependencies. One option is to get your upstreams on-board with your plans,
> but that's also a drain on resources. You also have to give up some control,
> which can be a difficult thing to accept.

The other problem of not following mainline is that it makes a project much faster
obsolete than it needs to be. Most users want to be able to install the latest
and greatest on their hardware, even if they do not need it... But they decide
for or against projects on that basis.