Yocto Technical Team Minutes, Engineering Sync, for July 14 2020

* Yocto Technical Team Minutes, Engineering Sync, for July 14 2020
@ 2020-07-16 20:05 Trevor Woerner
  2020-07-16 20:27 ` [yocto] " Paul Barker
  0 siblings, 1 reply; 2+ messages in thread
From: Trevor Woerner @ 2020-07-16 20:05 UTC (permalink / raw)
  To: yocto

Yocto Technical Team Minutes, Engineering Sync, for July 14, 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Trevor Gamblin, Jan-Simon Möller, Bruce Ashfield, Stephen
Jolly, Joshua Watt, Vineela, Alejandro H, Richard Purdie, Steve Sakoman,
Michael Halstead, Scott Murray, Tim Orling, David Reyna, Jon Mason, Jeremy
Puhlman, Ross Burton

== notes ==
- found/identified a fix for an AB issue
- looking for more help with bugs

== general ==
RP: the bug that was found in bitbake was from 3 years ago, really happy to
    find it and fix

JPEW: i missed the bug triage, did we get any new people
RP: sadly not

RP: working on making sure older releases (pre-LTS) can still build (thud)
Alejandro: how far back?
RP: AB2 code base doesn’t go back that far, so Pyro/Rocko should be do-able,
    beyond that probably not. i assume if i get thud working, the same will
    work for sumo etc
RP: a limiting factor is jinja2 which is used for results processing on the
    AB, usually we just use the tip, but that might not be viable for older
    releases
Timo: some of the issues are with ptests too?
RP: yes, ptests pulls in python tests which pulls in a huge list of
    dependencies

Timo: maybe move pytests into core?
Alejandro: why not have it in core?
Timo: the number of recipes (dependencies), who’s going to maintain, etc
Timo: note: i’m for including it in core
RP: i feel we should be expanding core, i’m in favour too
(various): sounds like a lot of agreement for having it in core
Alejandro: i’d like to get rid of anything that depends on pip
RP: agreed, it would be preferable if MH didn’t have to use buildtools
    manually on the AB
RP: (reads off the list of recipes that are pulled in)
Alejandro: so these are all in meta-python?
RP: yes
RP: i’ll put a proposal on the mailing list and see where it goes. Timo is
    the maintainer and is favourable to bringing it in
Timo: we’ve been getting lots of help from TrevorG and Leon (konsulko)
Timo: it would help to have this in core for other things that want to use it,
    would lead to greater use of testing
RP: we have special buildtools for different compilers, so there’s no reason
    we couldn’t have special versions for different release branches of the
    project

JPEW: does anyone use Lua
Timo: have used it, not extensively
Scott: it is used in AGL
JPEW: i’m using something that needs it, but “batteries not included”
Scott: i had to work with it a while back, there is a layer floating around
    out there somewhere (lua-rocks stuff) that has an npm-style tooling
JPEW: lua is in oe-core, wondering if there’s interest in a layer to add
    other lua stuff
Scott: the usage in AGL is pretty straight-forward
JPEW: i’ll put it somewhere
Scott: post in oe-devel see if there’s any interest
JPEW: wasn’t sure to make my own layer, or suggest it for oe-devel, there
    are opinions wrt layers based on languages

Timo: perl RDEPENDs stuff, was looking at some recipe-tool stuff (from 4 years
    ago), there’s meta-cpan that has a nice REST api, what do we do when the
    result is something that doesn’t have a recipe for it
RP: i have enough on my plate
Timo: was going to create a missing.txt file for any missing dependency
    results
RP: sounds good

Timo: inclusive language, upstream repos changing “master” to something
    else, we also use master and whitelist/blacklist
Jon: it’s going to be a lot of work, but if we can at least put it on the
    roadmap that would be good
Timo: 3.3 maybe
RP: don’t think we can put it off that long
JPEW: what’s the plan? keep old stuff around for a while? we use the same
    metadata with numerous versions. the branch names aren’t the issue for
    us, mostly variable names. in favour of a deprecation timeline
RP: we need to do more analysis: variable names, function names, branch names
    etc…
RP: in addition to the use “white” and “black” there are also issues
    over various names (i.e. some names are too cryptic) and there are issues
    with the behaviour of some variables
RP: my guess is that the hard part isn’t the technical issue of renaming,
    it’s the discussions around related issues, there’s a scope-creep
    danger above and beyond fixing the offensive bits

^ permalink raw reply	[flat|nested] 2+ messages in thread