minutes for Yocto Project Technical Team Meeting / Engineering Sync - June 9 2020

minutes for Yocto Project Technical Team Meeting / Engineering Sync - June 9 2020

[Trevor Woerner]

Yocto Technical Team Minutes, Engineering Sync, for June 9 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, Jan-Simon Möller, Stephen Jolly, Trevor Gamblin, Bruce
Ashfield, Scott Murray, Paul Barker, Michael Halstead, Jon Mason, Richard
Purdie, Joshua Watt, Armin Kuster, Tim Orling, Sathishkumar Duraisamy,
henriknj, Ross Burton, Jeremy Puhlman

== notes ==
- 2.7.4 released last week
- 3.1.1 built, but has issues, not sent to QA yet
- M1 early next week (to build)
- thanks to AlexK for lots of fixes

== general ==
RP:
    problems with 3.1.1. qemu(-mips?) failed with taskhash mismatches, not
    sure why


RP:
    devtool, patchtest, patchwork, and wic looking for maintainers
PaulB:
    patchtest/patchwork still on python2, needs 2→3 update. patchtest
    should be moved to OE-core so it can be noticed by more people


RP:
    lots of recipe upgrades, happy with where master is (wrt to recipe
    versions), still need to update qemu to 5


JPEW:
    did RP see my patch to mc-depends to make it backwards compatible?
RP:
    dismayed it was more complex than hoped, but looks okay
JPEW:
    i’m using a proxy object otherwise we need to duplicate a lot of code
    with a lot of if’s
RP:
    saw the BBMASK thing for multiconfig that needed index checking, sad
    that we’ll be stuck with that going forward (in command.py) mostly for
    backwards compatibility (e.g. file checking). another option is to have
    a new API and append a ‘2’ to the end so callers will call the right
    things (old or new). the code’s probably going to get worse and worse
    with every new parameter we want to add (in the future)

JPEW:
    re multiconfig, sometimes the old full “multiconfig” string
    doesn’t work but the new “mc” string does, can we drop
    “multiconfig”? changed in 2.7? or 3.0? there’s a bugzilla somewhere.
    some code handles both, some doesn’t
RP:
    we can get rid of it, despite the expected screaming


RP:
    re devtool, reports on mailing list that devtool isn’t mc-compliant
RP:
    we have a horrible hack for PRserver
RP:
    highlights the need for a dedicated maintainer


PaulB:
    re patchwork, kernel.org are using a newer version of patchwork that is
    python3-compatible, is maintained, but missing some things we need
Timo:
    i looked at freedesktop.org’s gitlab, they’ve made a lot of changes
    from where we forked from them, they’re also using python3 and django2.
    going with mainline will miss features that we’re used to
PaulB:
    make a list of the gap items, then decide if we can live without these
    things
Timo:
    i looked at the fd.o’s patchwork and saw that many of the things we
    added to our fork have been added (but differently) in fd.o’s. e.g. we
    added a superseded feature, doesn’t seem to be on any other patchworks
PaulB:
    would like to spin up concurrent patchworks to see how the react to the
    mailing list
Timo:
    good idea, maybe we can work together on that
PaulB:
    for patchtest it seems obvious what steps are required, patchwork less
    clear
Timo:
    https://gitlab.freedesktop.org/patchwork-fdo
Timo:
    might be a lot of work to compare ours with fd.o’s patch by patch to
    see
PaulB:
    we need to figure out if we can live with some upstream version, to cut
    down on the effort of having our own fork
RP:
    but it’ll cause a lot of pain if, for example, the superceded feature is
    missing
Timo:
    we’re better off putting resources elsewhere. upstream looks hard, but
    i think patchwork-fdo looks like it might work, maybe easier to submit to
    patchwork-fdo rather than upstream?
TrevorW:
    maybe fdo would really like a superceded feature, they split from
    upstream for same reasons as us, they probably share the same frustrations
Timo:
    agreed, we should reach out to them
RP:
    we should get a list first before reaching out
Timo:
    we probably have about 30 patches on top of upstream, although most of
    them of them are probably just to add the supercede feature
PaulB:
    is there anything in bugzilla? 13684 is a django update
PaulB:
    to take action to capture this discussion in bugzilla
Timo:
    Amber working on layerindex, but maybe we can have her work on this too
    (not a promise), she has a lot of django experience


Timo:
    re perl dependency. there’s an existing oe-package-data util script,
    i’m using almost exact same code in a bitbake task, should this be
    refactored to lib/oe?
RP:
    sounds good, but depends on the implementation, in general i’m in favour
    of strong APIs in lib/oe. e.g. “packagedata” is too generic. the
    history was that packagedata.py was created as a way of pulling code out
    of a bbclass

Re: [yocto] minutes for Yocto Project Technical Team Meeting / Engineering Sync - June 9 2020

[Tim Orling]

[-- Attachment #1: Type: text/plain, Size: 5809 bytes --]

On Tue, Jun 9, 2020 at 2:16 PM Trevor Woerner <twoerner@gmail.com> wrote:

> Yocto Technical Team Minutes, Engineering Sync, for June 9 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, Jan-Simon Möller, Stephen Jolly, Trevor Gamblin, Bruce
> Ashfield, Scott Murray, Paul Barker, Michael Halstead, Jon Mason, Richard
> Purdie, Joshua Watt, Armin Kuster, Tim Orling, Sathishkumar Duraisamy,
> henriknj, Ross Burton, Jeremy Puhlman
>
> == notes ==
> - 2.7.4 released last week
> - 3.1.1 built, but has issues, not sent to QA yet
> - M1 early next week (to build)
> - thanks to AlexK for lots of fixes
>
> == general ==
> RP:
>     problems with 3.1.1. qemu(-mips?) failed with taskhash mismatches, not
>     sure why
>
>
> RP:
>     devtool, patchtest, patchwork, and wic looking for maintainers
> PaulB:
>     patchtest/patchwork still on python2, needs 2→3 update. patchtest
>     should be moved to OE-core so it can be noticed by more people
>
>
> RP:
>     lots of recipe upgrades, happy with where master is (wrt to recipe
>     versions), still need to update qemu to 5
>
>
> JPEW:
>     did RP see my patch to mc-depends to make it backwards compatible?
> RP:
>     dismayed it was more complex than hoped, but looks okay
> JPEW:
>     i’m using a proxy object otherwise we need to duplicate a lot of code
>     with a lot of if’s
> RP:
>     saw the BBMASK thing for multiconfig that needed index checking, sad
>     that we’ll be stuck with that going forward (in command.py) mostly for
>     backwards compatibility (e.g. file checking). another option is to have
>     a new API and append a ‘2’ to the end so callers will call the right
>     things (old or new). the code’s probably going to get worse and worse
>     with every new parameter we want to add (in the future)
>
> JPEW:
>     re multiconfig, sometimes the old full “multiconfig” string
>     doesn’t work but the new “mc” string does, can we drop
>     “multiconfig”? changed in 2.7? or 3.0? there’s a bugzilla somewhere.
>     some code handles both, some doesn’t
> RP:
>     we can get rid of it, despite the expected screaming
>
>
> RP:
>     re devtool, reports on mailing list that devtool isn’t mc-compliant
> RP:
>     we have a horrible hack for PRserver
> RP:
>     highlights the need for a dedicated maintainer
>
>
> PaulB:
>     re patchwork, kernel.org are using a newer version of patchwork that
> is
>     python3-compatible, is maintained, but missing some things we need
> Timo:
>     i looked at freedesktop.org’s gitlab, they’ve made a lot of changes
>     from where we forked from them, they’re also using python3 and django2.
>     going with mainline will miss features that we’re used to
> PaulB:
>     make a list of the gap items, then decide if we can live without these
>     things
> Timo:
>     i looked at the fd.o’s patchwork and saw that many of the things we
>     added to our fork have been added (but differently) in fd.o’s. e.g. we
>     added a superseded feature, doesn’t seem to be on any other patchworks
> PaulB:
>     would like to spin up concurrent patchworks to see how the react to the
>     mailing list
> Timo:
>     good idea, maybe we can work together on that
> PaulB:
>     for patchtest it seems obvious what steps are required, patchwork less
>     clear
> Timo:
>     https://gitlab.freedesktop.org/patchwork-fdo
> Timo:
>     might be a lot of work to compare ours with fd.o’s patch by patch to
>     see
> PaulB:
>     we need to figure out if we can live with some upstream version, to cut
>     down on the effort of having our own fork
> RP:
>     but it’ll cause a lot of pain if, for example, the superceded feature
> is
>     missing
> Timo:
>     we’re better off putting resources elsewhere. upstream looks hard, but
>     i think patchwork-fdo looks like it might work, maybe easier to submit
> to
>     patchwork-fdo rather than upstream?
> TrevorW:
>     maybe fdo would really like a superceded feature, they split from
>     upstream for same reasons as us, they probably share the same
> frustrations
> Timo:
>     agreed, we should reach out to them
> RP:
>     we should get a list first before reaching out
> Timo:
>     we probably have about 30 patches on top of upstream, although most of
>     them of them are probably just to add the supercede feature


Captured notes and recent research/discovery in the bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13684

We have 49 commits since forking from patchwork-fdo.
Upstream patchwork-fdo has 166 commits since we forked.


> PaulB:
>     is there anything in bugzilla? 13684 is a django update
> PaulB:
>     to take action to capture this discussion in bugzilla
> Timo:
>     Amber working on layerindex, but maybe we can have her work on this too
>     (not a promise), she has a lot of django experience
>
>
> Timo:
>     re perl dependency. there’s an existing oe-package-data util script,
>     i’m using almost exact same code in a bitbake task, should this be
>     refactored to lib/oe?
> RP:
>     sounds good, but depends on the implementation, in general i’m in
> favour
>     of strong APIs in lib/oe. e.g. “packagedata” is too generic. the
>     history was that packagedata.py was created as a way of pulling code
> out
>     of a bbclass
> 
>

[-- Attachment #2: Type: text/html, Size: 7498 bytes --]