From: "Trevor Woerner" <twoerner@gmail.com>
To: yocto@yoctoproject.org
Subject: Yocto Technical Team Minutes, Engineering Sync, for July 28 2020
Date: Tue, 28 Jul 2020 18:41:49 -0400 [thread overview]
Message-ID: <20200728224149.GA22506@linux-uys3> (raw)
Yocto Technical Team Minutes, Engineering Sync, for July 28 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, Stephen Jolly, Armin Kuster, Josef Holzmayr, Richard
Purdie, Trevor Gamblin, Joshua Watt, Mark Morton, Ross Burton, Bruce
Ashfield, Steve Sakoman, (phone-in ??), Jon Mason, Randy MacLeod, Scott
Murray, Denys Dmytriyenko
== notes ==
- fixed a race on AB wrt perl
- 3.1.2 into QA
- 3.2-m2 to QA once they’re done with 3.1.2
== general ==
RP: load of perl issues over the weekend, believe to have found issue
RP: lots of qemumips issues, not sure why, perhaps a timeouts issue? (no ping
within 30 seconds)
RP: some infrastructure issues (one worker has become corrupted)
RP: curious to know what people think about 3.1.2: there is a bitbake issue
with toaster, should we release then fix or wait for fix before release?
SS: maybe we should get feedback from people using toaster
RP: the fix is simple, maybe release 3.1.2 (with release note) then fix
RP: merged re-arrangement of package manager code, this puts more of our code
into python libraries instead of bbclass files, which is the direction i
want to take going forward
RP: i need to start a conversation on oe-architecture for future directions
RP: e.g. binary package feeds, we want to capture these use-cases into the
wiki
[NB: done! see https://wiki.yoctoproject.org/wiki/Future_Directions]
RP: we also posted the current agreement on “inclusive language” as agreed
on by various groups (oe board, oe-tsc, yp-tsc)
TW: what’s the thinking behind moving code to libraries vs bbclass?
RP: pro: parsing speed con: variable dependency tracking is lost
RP: lots of python code gets written to logs etc, which slows it down
JPEW: does bitbake automatically detect variable dependencies in library code?
RP: no. maybe we just need to do the scan once?
TW: do we lose flexibility? (e.g. it’s easy to copy+paste+modify a bbclass,
will that be possible?)
RP: there will still be all the same entry points, so it should be possible
RP: i’m worried about the size of the datastore in memory and it is a
bottleneck
RP: i wonder why qemumips is so slow?
Randy: i think Cisco are the only ones caring about mips
RP: yes, and Comcast too i think
MM: have been wrapped up in $WORK stuff, but will be working on docs
conversion soon
RP: MH has been putting infrastructure in place and Nico is looking forward to
getting this going
MM: do we want to try to reproduce our current colours/formatting or try
something new
RP: i like what we have, the project does have an existing scheme, but we can
change if something else makes sense
TW: i do lots of builds, never seen issues, why are there so many failures on
AB?
RP: do you do oe-selftest or testsdk builds?
TW: no
RP: do you do mips builds?
TW: no
RP: so these are the areas where we see these failures, “regular” builds
are okay
SS: i don’t see issues on my builds but that’s probably because of working
these issues out on the AB
RP: infrastructure issues are low, it’s mostly race issues that come out of
the extreme load of the AB or intermittent architecture issues that are
rarely tested
next reply other threads:[~2020-07-28 22:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 22:41 Trevor Woerner [this message]
2020-07-29 7:36 ` [yocto] Yocto Technical Team Minutes, Engineering Sync, for July 28 2020 Nicolas Dechesne
2020-07-31 20:06 ` [docs] " Mark Morton
2020-07-31 20:36 ` Nicolas Dechesne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200728224149.GA22506@linux-uys3 \
--to=twoerner@gmail.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.