Yocto Technical Team Minutes, Engineering Sync, for August 18, 2020

["Trevor Woerner" <twoerner@gmail.com>]

Yocto Technical Team Minutes, Engineering Sync, for August 18, 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 Jolley, Armin Kuster, Josef Holzmayr, Joshua Watt,
Tim Orling, Jan-Simon Möller, Mark Morton, Randy MacLeod, Alejandro,
Michael Halstead, Jeremy Puhlman, Richard Purdie, Scott Murray, Paul
Barker, Mark Asselstine, Martin Jansa (JaMa)

== notes ==
- 3.2-m2 released last week
- 3.0.4 (last of zeus) going through QA curruently (out in next day or so)
- sharp increase in AB bugs (intermittent)
- AUH upgrade script failed
- trying to drop fno-common scripts from gcc

== general ==
RP: trying to cleanup the fno-common vs not-common gcc patches, thanks Khem

RP: there has been good work to fix proper back tracing

RP: intermittent AB issues, got leads in some, struggling in others. not a lot
    of people with which to discuss these (never mind fix)
Randy: we’ve been able to reproduce some of these on a different setup, but
    not many
RP: i don’t think one needs to setup a clone of the AB in order to reproduce
    these issues, simply run some of the builds (oe-selftest) with various
    loads (cpu, I/O) on the rest of the system. Armin tried this and was able
    to see them
Armin: and more, actually
(various): using a VM helps
Timo: point being, an idle system rarely shows any of these issues

Timo: did we fix the 500 issue?
MH: we definitely were able to fix the one SS reported
RP: i was able to find a reproducer over the weekend and gave it to SS, MH:
    did you document/close the issue?
MH: i will

RP: for one of the tests, the solution seems to be to extend the timeout from
    5s to 10s. we’ll see what failure rate we get at 10s

Armin: bind and dhcp. not sure if we want to replace things, or have things
    co-exist
RP: going forward i think we’re going to switch over, so might as well bite
    the bullet and switch

RP: speaking of compatibility… i pulled out the packaging code (PRserv and
    hash equivalence) PRserv is deprecated in favour of hash equivalence

RP: we’re staying close to upstream thanks to AUH, please send out updates.
    some packages still need manual maintenance (i.e. qemu)
Randy: did you create a defect for it? i can
RP: please do

Armin: future planning, since we have an LTS now, any benefit to plan for next
    LTS? (i.e. bigger, larger changes)
JPEW: when is the next LTS
Armin: technically, in 3 more releases
SJ: so 3.5 or so
Paul: the longer the timeframe, the worse the predictions
Timo: chance some features will not get the testing they would otherwise
RP: historically we’ve experimented with different release cycles, causes
    too much load for some releases, “stampeding herd” effect for
    patches/QA. our current system seems to be the “happy medium”
Armin: i wasn’t proposing to change the milestones or the current release
    system
Paul: i think the proposed features page on the wiki is probably the best
    place to look (https://wiki.yoctoproject.org/wiki/Future_Directions)
RP: or bring it up with the TSC. we’re struggling more with contributors
    rather than planning. we could fill in the target milestones better in the
    bugzilla (talk to MH to get more added)

Paul: what are you proposing for the process to modify that page?
RP: probably best to discuss on ml before simply updating the page, the list
    is of things that have already been vetted by the TSC. do you have any
    ideas?

Paul: LF core infrastructure list of “best practices”
    (https://bestpractices.coreinfrastructure.org/en/projects?q=yocto)
RP: we’ve taken a look at that already, we have a badge! e.g. need to run
    pylint, has been added (now someone has to look at the results)
Armin: we don’t advertise that we have the badge, we should put it on the
    website somewhere
Randy: i’d like to know more about the pylint
RP: just used in a couple places for now, want to add more later. lots of
    output, we don’t care about some things. we need a profile to teach the
    linter what things are “don’t care” (e.g. line length)
Timo: looked at some of the linting stuff Conrad (Siemens?) was doing
RP: Ross and I looked at some of the linter output and it does catch some good
    things. the future directions page needs to be advertised more
Paul: can’t figure out which things are YP vs OE
RP: depends on which TSC discusses it
Timo: hard to figure out how people can find things

RP: docs, have been working on the version selection stuff, updating links to
    point to “read the docs” links
Randy: is the Sphinx stuff visible yet?
RP: not quite, see the status updates on the docs ml
Randy: need to subscribe
RP: seems we need more mailing lists (e.g. AB output). naming is the issue
Timo: 7 people → 10 suggestions

RP: any thoughts on an AB list. a list for AB patches. “yocto-autobuilder”?
Armin: sounds fine
RP: needs to be better than “yocto-builds”, which is too ambiguous
TrevorW: maybe add “-dev” to the name?
RP: seems there’s more problems adding “-dev” and separating the people
    into “developers” vs “users”
Armin: just don’t use AB to refer to it! (i.e. advisory board vs autobuilder)
Timo: and not let the names get too long