Dear Community members, Tianocore community meeting is coming up this week, on 2/4 from 9am-10am (PST) and 7.30pm-8.30pm (PST). Please resync and subscribe to the calendar

TianoCore Community Meeting Minutes December 10, 2020 EVENTS: No new updates. STABLE TAG: * Stable tag (edk2-stable202011) has been completed. * Upcoming 202102 stable tag features

Hi, all The tag edk2-stable202011 has been created. https://github.com/tianocore/edk2/releases/tag/edk2-stable202011 git clone -b edk2-stable202011 https://github.com/tianocore/edk2.git The

Hi, all edk2-stable202011 tag will be created on 2020-11-27 (UTC-8 00:00:00). It will base on current edk2 trunk (the latest

Hi, all Today, we enter into Hard Feature Freeze phase until edk2-stable202011 tag is created at 2020-11-27. In this phase, there is no feature to be pushed. The critical bug fix is still allowed.

Hi, all We will enter into Soft Feature Freeze phase. In this phase, the feature under review will not be allowed to be pushed. The feature passed review can still be merged. Now, most planning

TianoCore Community Meeting Minutes November 12, 2020 EVENTS: No new updates from last month (below). Given COVID-19 travel restrictions, the UEFI Forum is delaying U.S. based Plugfest until next

Dear Community members, Our next community meeting is on the 12th of November from 9am-10am (PST) and 7.30pm-8.30pm (PST). We will be using Webex moving forward since we had good experience during

Thanks for all the feedback team. All your feedback was incorporated, and final rev was discussed and finalized during the Stewards meeting this week. The page is live here -

TianoCore Community Meeting Minutes October 8, 2020 EVENTS: Update from Dick Wilkins on UEFI plugfest: Given COVID-19 travel restrictions, the UEFI Forum is delaying U.S. based Plugfest until

Dear Community members, I have updated our October community meeting with Webex. Please resync your calendar so you have the latest meeting invite. Some of them have experienced issues with blue

(Resending; my previous attempt to post this response failed, and I even lost the original version of my response, so I'm rewriting it again from a draft. I've also cleaned up the garbage in the

Hi Folks, Thanks for good discussions around this topic. The purpose of this document "Who we are" is intended to remain high level to introduce the community members and their roles. Please note

I think you're right. This is why we seem to have two sets of opinions on this topic. Right, that makes sense to me. If I was to start bikeshedding, I might suggest adding an A: tag for approving

oops, this was a meaning-destroying typo. I meant: "chief maintainers". Thanks Laszlo

I disagree. Assume Ard and myself are away and Jordan fails to report back in a week or so, but Rebecca or Peter have reviewed a patch on the list for OvmfPkg/Bhyve. In that case, the patch should

As far as I remember, the intent to designate reviewers in the Maintainers.txt file was (a) to highlight people that consistently review patches for a subsystem *without* having push rights, (b) to

This is the best resolution in my opinion. It allows maintainers to delegate the technical review to reviewers, but it requires maintainers to be at least aware of the patch and the review

Agreed. Reviever or Maintainer can approve a patch. Any Maintainer can push a patch that has been approved. This can happen either: - when the designated Maintainer for that patch is

Jiewen: Frankly speaking, I don't know this rule that the patch needs to get review or ack from the maintainer. When the reviewer name is formally added into maintainers.txt, I think the maintainer