[Openembedded-architecture] Layer compatibility markup proposal

[Richard Purdie]

On Fri, 2017-06-02 at 13:07 -0400, Denys Dmytriyenko wrote:
> On Fri, Jun 02, 2017 at 12:51:14PM -0400, Philip Balister wrote:
> > So this gives us a way to flag to users that they are working with
> > a likely bad combination of layers. This is a good thing.
> > 
> > But, how do we explain how to fix the situation?
> > 
> > We can explain how to add the lines so the layer tries to build,
> > but if it fails what then? Ask what recipes the user is looking for
> > and copy to another layer? This would make sense for poorly
> > designed layers, but in many cases, the problem we need to solve is
> > supporting layer maintainers better.
> > 
> > As adoption of OpenEmbedded has exploded, it led to a dramatically
> > increases workload across the entire project. Beyond just the core
> > layers. This leads to maintainers being overwhelmed by requests for
> > help with something they published, and then seeing people back off
> > as they get overwhelmed by demand for support for something they
> > put together to support a specific project.
> > 
> > I am really interested in the question of how we build up the
> > project, preferably without dividing into pieces as part of the
> > process.
> Nicely put, Philip!
> 
> I agree that part of the issue is with the recent influx of new users
> demanding support for their own use cases, which might not have been 
> planned out or even implemented by maintainers. Many maintainers are 
> still driven by their own needs first. So, erroring out may help with
> spotting any incompatibility issues early on, but won't help much
> with fixing those... Right?

At a simplistic level, getting a message that layer X is incompatible
with version Y of the project is infinitely preferable as a workflow
scenario. This way at least the user knows it hasn't been tested and
isn't expected to work. At this point sure, they can ask the layer
maintainer to add support but they can respond, "sorry its not
supported", perhaps indicating if they ever plan to. This is much
better than the current "its broken, why can't you fix it?", the layer
maintainer struggling to figure out what combination of things they
tried and the user walking away saying "OE is rubbish".

It also would then mean someone has a target to implement and an
incentive to send a pull request to the maintainer fixing it, at least
in theory. Currently its much less clear what the issue is, let alone
how to help.

I don't think there is any magic one thing to fix things but there are
many things which can and in some cases are being done to help:

* We're working on tools which help layer maintainers do things like
recipe upgrades so they can spend more of their time on more
interesting problems.

* There are widely differing standards of layers. YP Compat v2 is being worked to help try and address various interoperability concerns. This isn't just about validating what we do today but actually finding ways to do it better and make things more interoperable (see the proposal that triggered this).

* There is a "drop off a cliff" between the YP Quick Start and the 
reference docs. I do want to see that fixed. The YP advisory board did
approve extra funding on documentation to help with various issues.

* The YP website sucks and doesn't help. That is being worked on.

* Layer metrics in the layer index are being discussed. This would set
better user expectations of a given layer.

* Newcomer docs and guidance is being improved and Stephano agreed to
look at this area at the last developer meeting.

* Often users hit unclear errors. Where these are reported, we've
committed to and do try and improve them so they're more
understandable.

* Many of us watch stack exchange and answer questions there, trying to
create a community knowledge base.

* Tools like devtool and eSDK are being actively developed so not
everyone is exposed to the build system.

* I also have a plan in mind for a setup tool to try and unify the way
we work with layers. I need to find time to write up a mail about that.

I find it all to easy to lose track of all the things we are doing, I'm
pretty sure there are other things I've forgotten too. Not all these
directly support the layer maintainer but they should all help a little
in some way.

There are some things which worry me:

* Bug trends are on the up. There are few people who work on core bug 
fixing, let alone the other layers.

* Many of the 'same old' suspects are the ones trying to do the
initiatives above (and beyond). We need more new blood. Some existing
maintainers are burning out, sadly me amongst them.

* There is turmoil at many of the companies involved in the project and
this may change the way some people are able to spend time doing what
they do today.

* The scalability model for OE is split layers. I still think some
layers may benefit from doing this to effectively load balance.

* Our automated testing outside the core could do with improvement.
I've been trying to think of creative ways we could extend that.

* Some age old 'discussions' keep coming up. Burying the hatchet on
some of them would probably help.

I'd also like a pony. Actually, I wouldn't, perhaps a new motorcycle?
:)

Seriously, if there are things we're not doing which we could do to
improve things for the maintainers please shout up. We are already
trying to do a lot though (and risking further burnout).

Cheers,

Richard