[LEDE-DEV] Talks between OpenWrt and LEDE

[Daniel Dickinson]

On Wed, 21 Dec 2016 13:06:22 -0500
"Hauke Mehrtens" <hauke at hauke-m.de> wrote:

> We had multiple meetings to find a solution to solve the problems
> between the OpenWrt and the LEDE project and to discuss a possible
> merge. Everyone with commit access to LEDE and all OpenWrt core
> developers were invited to these meetings. We had productive and
> friendly discussions about the problems and our goals.

Congratulations to both sides on finding a path back from a bad
situation that my personal issues exacerbated.  I hope the combined
project can move forward in a positive new environment.

> It is still not decided that both project will finally merge and we
> haven't decided on the name to use, which parts of the infrastructure
> and many other things. In general we are agreeing on many parts and I
> am looking forward to a good merged ending for all of us.

I agree with those on this thread that suggest changin the name but in
a Co-Branded manner to being with.

As part of this those I'm thinking that having a more
'commercial-quality' flavour and a more 'community' flavour branches
would be useful.

I know that one of the struggles with OpenWrt in the past has been a
lot of decisions for expediency and/or testing bleeding edge stuff.

I'm thinking that the 'commercial-quality' flavour should look more
like the type of hard-core approach of the modern linux kernel; one of
the problems the kernel had when growing up, which I think is mirrored
in openwrt/lede is a shift from a less structured community of
'hackers' (not in the cracking sense), to a core infrastructure
project, that has made the main kernel a less approachable project for
those who aren't professionally involved in kernel work, but has been
necessary for code/kernel quality.

I've thought of a couple of different ways of looking at this.

There is the approach that says that OpenWrt/LEDE concentrates on the
build system (kernel + minimum set of packages, but also ubus, ubox and
other core components to produce an SDK that is used to build everything
else; and doesn't not by itself produce a working firmware image).
This includes things like wifi components where untested code should
not be part of what non-engineers are working on or being exposed to in
a proper wifi test lab.

The next level of that would be having different 'integration layers'
which combine the core components plus relevant other packages into a
useful 'product'.

The purpose of the integration layers is to allow experimentation and
community development of for some layers, which is more bleeding edge
and/or 'many eyes makes all bugs shallow', vs. the current stated core
mission which is a 'commercial-quality' router firmware, which
integration layer would be subject to more stringent standards and QA
practices (but could benefit from community developed
features/enhancements/bug requests).

Ideally for the commercial-quality router integration layer the
ecosystem of businesses benefiting from OpenWrt/LEDE would step up and
participate in kernel-esque collaboration.

Another approach says that the 'core mission' is the only thing there
is really the manpower for in the forseeable future and moves the
project to a more kernel-esque level of rigour, including the relevant
subset of the various packages feeds and luci that are part of the
'commercial-quality firmware', and split out the community parts so
that they don't detract from the primary efforts.

Unfortunately I'm not sure how much I can contribute to either effort;
I'm interested but not sure that this is how I ought to be using the
bulk of my time, and I'm not sure a community edition really has enough
people with enough time to make it work.

That's in part why I think having a core SDK, plus a cherry-picked
'commercial-quality' sets of feeds is the way to go; it allows
community users to concentrate on efforts that not only interest them
part aren't doing more harm than good.  Certainly there will be some
community members who will participate in both, but I think for the
benefit of the 'core mission' raising the bar on the core parts is a
necessary step even though it will be painful.  However, I think it
would be helpful to have a little blurb about *why* and *what* change
is being implemented both on the site and on commit templates, so that
contributors are less likely to be taken by surprise with the hard-core
approach.

When I first saw the fork I thought a way to refresh community but now
I'm thinking David Woodhouse's approach is more appropriate for the
'core mission', and community efforts ought to be more like 'Linux
Mint' (only community) on top of the core distro.

In large part the difference for me has been what I was having medical
issues leading to vocal and unhelpful thinking and messages and now
that I have recovered I see a great deal more value in the rigorous
approach, at least for the core.

Regards,

Daniel