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

Dear Community members, Our next community meeting is on the 8th of October from 9am-10am (PST) and 7.30pm-8.30pm (PST). Please resync and subscribe to the calendar so you have the

Soumya: Do you mean to directly modify wiki page? Or, send the update content as the patch for your integration? Thanks Liming

Laszlo: I agree this point. The guideline is to collect the feedback in one week, not the deadline to finish the code review. Thanks Liming Michael D' please than a reviewer. But, or

Hi Liming, This requirement is about providing initial feedback. In other words, about starting the review. It's very important to provide initial feedback within a week. I agree that more time

Jiewen, Good point on the release maintainer definition - we need to add this. Yes I think we need to add those guidelines for maintainer. (Please keep in mind to separate the role vs process,

Hi Jiewen, My view is that a reviewer has a right to "approve" a patch, but they do not have access to actually push the patch. A maintainer is needed for that. In instances where a designated

Hi Liming, My take on this is as follows (speaking as someone who has failed this rule many times): This document is a guideline. In some cases we are not yet in a position to be more timely about