Layer compatibility markup proposal


Richard Purdie
 

Hopefully this is a simple and uncontroversial idea :)

I'd like to be able to set something like this in OE-Core's layer.conf
file:

LAYERSERIES_CORENAMES = "rocko"

and then layers would set something like:

LAYERSERIES_COMPAT = "rocko"

It would become a hard requirement for Yocto Project Compatibility v2
to have this set.

If a layer sets _COMPAT but doesn't have an overlapping namespace, it
would error.

We'd suggest layers use the next as yet unreleased codename by default
so that when OE-Core releases, things "ripple" through the system with
minimal disruption as people release from master to stable branches at
a staggered rate. I had toyed with a "master" keywork too but I think
that works against us.

I'd would be possible for a layer to be marked as compatible with
multiple release series, at the maintainers discretion.

In case its not clear, the intent here is so that someone trying a
master branch of some unmaintained layer gets a clear error about
whether its compatible or not. Obviously someone can easily tweak the
layer to remove the error but it would stop a very common new user
experience issue we have.

I guess a slightly more controversial idea would be backporting this to
some of the stable releases? :)

Any thoughts on this?

[I've been thinking about this for a while but finally wrote the idea
down]

Cheers,

Richard


Burton, Ross <ross.burton@...>
 


On 2 June 2017 at 14:49, Richard Purdie <richard.purdie@...> wrote:
Any thoughts on this?

Yes yes yes yes.

(yes)

Ross

PS yes


Randy MacLeod
 

On 2017-06-02 10:05 AM, Burton, Ross wrote:
On 2 June 2017 at 14:49, Richard Purdie <richard.purdie@... <mailto:richard.purdie@...>> wrote:
Any thoughts on this?
Yes yes yes yes.
(yes)
Ross
PS yes
Maybe, err I mean YES!
This would help new users.

../RandYes

_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5


Philip Balister
 

On 06/02/2017 11:19 AM, Randy MacLeod wrote:
On 2017-06-02 10:05 AM, Burton, Ross wrote:

On 2 June 2017 at 14:49, Richard Purdie
<richard.purdie@...
<mailto:richard.purdie@...>> wrote:

Any thoughts on this?


Yes yes yes yes.

(yes)

Ross

PS yes
Maybe, err I mean YES!
This would help new users.
I'm going to derail the conversation a bit ....

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.

Philip


../RandYes



_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@...
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


Denys Dmytriyenko
 

On Fri, Jun 02, 2017 at 12:51:14PM -0400, Philip Balister wrote:
On 06/02/2017 11:19 AM, Randy MacLeod wrote:
On 2017-06-02 10:05 AM, Burton, Ross wrote:

On 2 June 2017 at 14:49, Richard Purdie
<richard.purdie@...
<mailto:richard.purdie@...>> wrote:

Any thoughts on this?


Yes yes yes yes.

(yes)

Ross

PS yes
Maybe, err I mean YES!
This would help new users.
I'm going to derail the conversation a bit ....

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?

--
Denys


Philip Balister
 

On 06/02/2017 01:07 PM, Denys Dmytriyenko wrote:
On Fri, Jun 02, 2017 at 12:51:14PM -0400, Philip Balister wrote:
On 06/02/2017 11:19 AM, Randy MacLeod wrote:
On 2017-06-02 10:05 AM, Burton, Ross wrote:

On 2 June 2017 at 14:49, Richard Purdie
<richard.purdie@...
<mailto:richard.purdie@...>> wrote:

Any thoughts on this?


Yes yes yes yes.

(yes)

Ross

PS yes
Maybe, err I mean YES!
This would help new users.
I'm going to derail the conversation a bit ....

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?
And to be clear, an error that says this hasn't been validated is better
than your typical confusing message when layers are not version matched.

Philip


Trevor Woerner
 

I agree 100% with Philip and Denys; but are either of you suggesting
we shouldn't implement this as a result of what you've mentioned (I
don't think so)?

Even though your points are 100% spot-on, I still think we should go
ahead with the proposal. I just want to make sure your comments don't
dissuade the implementation if that wasn't your intent.


Otavio Salvador
 

On Fri, Jun 2, 2017 at 5:59 PM, Trevor Woerner <twoerner@...> wrote:
I agree 100% with Philip and Denys; but are either of you suggesting
we shouldn't implement this as a result of what you've mentioned (I
don't think so)?

Even though your points are 100% spot-on, I still think we should go
ahead with the proposal. I just want to make sure your comments don't
dissuade the implementation if that wasn't your intent.
One possible way to mitigate the issue is raising a big warning but
failing completely. This makes clear that it may fail but does not
enforce a manual action to continue.

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750


Philip Balister
 

On 06/02/2017 05:26 PM, Otavio Salvador wrote:
On Fri, Jun 2, 2017 at 5:59 PM, Trevor Woerner <twoerner@...> wrote:
I agree 100% with Philip and Denys; but are either of you suggesting
we shouldn't implement this as a result of what you've mentioned (I
don't think so)?

Even though your points are 100% spot-on, I still think we should go
ahead with the proposal. I just want to make sure your comments don't
dissuade the implementation if that wasn't your intent.
One possible way to mitigate the issue is raising a big warning but
failing completely. This makes clear that it may fail but does not
enforce a manual action to continue.
I'm arguing with myself which is better:

1) Fail, person goes online and told how to work around to see if layer
builds

or

2) Have a warning to automate this process.

The underlying problem RP is talking about is serious, but we need to be
thinking how we will handle problems as they arise.

Philip


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


Richard Purdie
 

On Fri, 2017-06-02 at 18:26 -0300, Otavio Salvador wrote:
On Fri, Jun 2, 2017 at 5:59 PM, Trevor Woerner <twoerner@...>
wrote:

I agree 100% with Philip and Denys; but are either of you
suggesting
we shouldn't implement this as a result of what you've mentioned (I
don't think so)?

Even though your points are 100% spot-on, I still think we should
go
ahead with the proposal. I just want to make sure your comments
don't
dissuade the implementation if that wasn't your intent.
One possible way to mitigate the issue is raising a big warning but
failing completely. This makes clear that it may fail but does not
enforce a manual action to continue.
FWIW my intent was always to make this a hard error. If the user wants
to avoid it they'd have to change something.

Cheers,

Richard


Philip Balister
 

On 06/02/2017 06:15 PM, Richard Purdie wrote:

I'd also like a pony. Actually, I wouldn't, perhaps a new motorcycle?
:)
I've seen the pictures of his motorcycle, he needs a new one. Or he
should just quit doing crazy stuff on it.


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).
This is a bigger problem than a technical list can solve. If consumers
of open source projects can't work out how to support the core projects
they depend on, chaos will occur.

Philip



Cheers,

Richard


Denys Dmytriyenko
 

On Fri, Jun 02, 2017 at 04:59:25PM -0400, Trevor Woerner wrote:
I agree 100% with Philip and Denys; but are either of you suggesting
we shouldn't implement this as a result of what you've mentioned (I
don't think so)?

Even though your points are 100% spot-on, I still think we should go
ahead with the proposal. I just want to make sure your comments don't
dissuade the implementation if that wasn't your intent.
I'm not suggesting doing nothing at all - something is better than nothing.

But I'm wondering out-loud about the problem in a bigger picture - maybe we
are moving too fast implementing major features and breaking APIs and are too
eager obsoleting old ones? And not just APIs, but "ways" of doing things in
general - we often come up with a better new way for something...

--
Denys