public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Brian Richardson" <brian.richardson@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>
Subject: TianoCore Community Meeting Minutes 12/05/2019
Date: Fri, 6 Dec 2019 04:11:37 +0000	[thread overview]
Message-ID: <80AC2BAA3152784F98F581129E5CF5AFCAF9CD09@ORSMSX114.amr.corp.intel.com> (raw)

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

(note: merged meeting minutes from both sessions)

Topics:
*        Stable Tag
*        CI
*        FOSDEM
*        Groups.io issues w/ patches
*        2020 Q1 Planning
*        HBFA & Unit Testing
*        Code First

Stable Tag 201911 has been released. Thanks to everyone who contributed. Small delay on release due to github administration issues, may need to create another admin level for release engineers.

CI data now displayed on main page for edk2 github repo.

FOSDEM - Feb 1-2, 2020 in Brussels
*        Submissions to open source firmware track from Intel & Linaro
*        Acceptance notices should be sent on Dec 8

Groups.io issues w/ patches
*        Seeing issues with large patch sets (over 40 items). Mike Kinney investigating. This has been observed by multiple users, so it is likely a groups.io "feature". Gitconfig can batch large e-mail patch sets with delays as a workaround. Red Hat will experiment on configuration.
*        Lazlo has seen inconsistencies with names used e-mail, which causes problems with commit history. Switching computers or environments can cause problems in gitconfig. Possible issues with Outlook/Exchange server (seen with some e-mails sent from intel.com).
*        Goal is to update best practices for gitconfig, including Python helper script.
*        Change in domain should be considered a different author. Requires additional review to make sure this is the same person.
*        Note: Issues this like have motivated the conversation for changing workflow from e-mail patches. Need to revisit new workflow & resolve in community.

2020 Q1 Planning
*        Rush of patches ahead of soft freeze date. Need to be proactive for each stable tag release & avoid this problem.
*        Developers should be focused on large/high-risk changes first, then move to lower priority/complexity issues. Reduces risk & thrash.
*        Metrics for bugs & features: size of patch set, algorithmic complexity, value with changes to critical code (even if changes are small, are risks justified versus benefits?). Measure as part of bug scrub, can push to next stable tag if deadlines cannot be met.
*        Mike is investigating Bugzilla fields that can help manage this process (existing or new additions).
*        Is there measurement criteria when moving code from edk2-staging to edk2 main repo? This is the responsibility of the staging branch owner. May need to spell this out as part of the exit criteria when staging code is elevated to master edk2 repo (testing APIs? How many platforms were used for validation?)
*        New protocols? Ok to add new EDK II APIs. If they impact UEFI spec updates, that is related to the code first initiative (different discussion, see below).
*        How is security mapped to risk assessment? Need to make sure this is covered.

HBFA & Unit Testing
*        Brent @ Microsoft has sent a proposal to add HBFA to CI process for unit testing (with examples).
*        Goal: Simplify process to add new unit tests & related APIs. Initial focus at library level. Module level has challenges in host environment (mocked interfaces can be complicated, shouldn't be more complex than the actual test). Infrastructure should take burden of complexity of test cases (instead of developer).
*        Framework should support multiple frameworks under the test directory. Staring with HBFA, but not assuming a single framework.
*        Stewards will review current proposal & provide feedback. Feedback is encouraged from the community on the edk2 rfc list.

Code First - still work in progress
*        Accessibility - Andrew @ Apple working on text-to-speech & related audio protocols in emulator.
*        Leif @ Linaro still working on code first proposal. Will send to edk2 rfc list when ready.
*        Naming conventions will clearly identify pre-spec & post-spec work.

Brian will be on vacation on Jan 2, 2020 (next scheduled community meeting). Will find different meeting owner for that date.

Thanks ... br


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

                 reply	other threads:[~2019-12-06  4:11 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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-list 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=80AC2BAA3152784F98F581129E5CF5AFCAF9CD09@ORSMSX114.amr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox