# 5th May 2022, 6:00 - 7:00 am UTC+0
Attendees: Anastasia, David, Edward, Felix, Nico, Nikolai, Thomas
## Decisions Summary
* Thomas gets submit rights * We want a separate reviewers group for flashrom so that reviewers are not mixed across different projects * Different tags for bug IDs are needed so that Google IDs (non-public) are not mixed with tickets from the flashrom issue tracker (public) * The mailing list should be used more for design discussions
## Agenda
* [aklm] I wanted to remind that we have an ongoing item “to figure out criteria to give people submit rights”. It was raised on the very first meeting. I think it is in many people's heads. * There is a thread on the mailing list “Gatekeeping, ACLs and Review Rules” ([link](https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/UFIVU... )). The topic is in scope of the thread. Currently the last message is mine, I can’t just talk to myself on the topic. Please share your thoughts! * In the absence of criteria I want to nominate Thomas to get submit rights. This is also an idea from the very first meeting. * In addition to commit stats that Martin gave in the first meeting, I have more points * Thomas is active on the project for a while, * he will be a gsoc Mentor, teaching our new contributors * Reachable and responding on the irc, by email, mailing list * Yes, no objections! * We need rules for this. Not too many people should just get submit rights so that we can keep track. * Separate Reviewers group for flashrom, everyone agrees. * Nik: better have a restricted group for Reviewers, and everyone can submit. * Let’s give Thomas submit rights. Congrats! * Anything that’s left to discuss from the item: “(in case somebody knows) What is Google’s current strategy to avoid repeating mistakes of the past?” * [dhendrix] Is this the kind of finger pointing that Edward mentioned above? At this point, CrOS has proved more than happy to move upstream. The Github mirror is probably more of a concern. Perhaps upstream should consider how to get developers to choose upstream rather than the Github mirror or some other fork. * [Nico] Pointing at Google, actually. If one company forks and later wants their code upstream without proper review, something seems wrong. As if they never reflected about the problems. * [aklm] I am not sure we are on the same page on what are “mistakes of the past”. Everyone has their own idea on what the mistakes were. I can start from myself. From my observations, converging the code was considered a purely technical task, and so it was done as a technical task. However, converging the code means converging the people/the teams, converging very different workflows and work cultures. This does not seem to be thought through or ever discussed, and to me this is a mistake. * Thomas : put GOOGLE_BUG tag and BUG is for public issue tracker * Edward BUG=g:1234566,b:544 * Edward: happens more on board bringup * Nikolai: maybe keep b: prefix for google bugs BUG=b:google_id,f:flashrom_id * Felix : [https://doc.coreboot.org/infrastructure/services.html#issue-tracker%5D(https...) * [quasisec] I am also unclear how CrOS convergence had really much of an impact on upstream considering >99% of the work was adjusting the CrOS fork to realign with upstream. Only an extremely small amount of alignment was in the form of upstream commits, e.g., missing raiden_debug and some unfortunate part of sb600spi. Is there a specific area that stands out? * [Nico] No idea if related to the original reasons for the fork, but that the convergence is stalling new releases for years stands out pretty much. * [Nico]: How can we teach developers who got to know the [Chrome OS] fork first about the upstream project (if not during review)? * [PatrickG] Once upstream-first is established, downstream patches aren’t reviewed anymore and redirected to upstream. * [quasisec] I am not sure anyone really “got to know the fork” as such. The problem was the fork was treated as a means to an end. Hence all the additional investment in improving flashrom such as life-cycle API and unit-testing to name some recent examples. Other examples include upstreaming additional hardware support such as lspcon, mst’s and raiden or later generation PCH rev’s. * [quasisec]: Regarding “teaching” can you elaborate on what this actually means as I think there is more than one dimension to the intent of that. * [Nico] I see a lack of a forum to teach people about the project. Because the mailing list is basically rejected by Google developers (with exceptions of course), and people ask to keep comments on Gerrit to very specific “actionable” items, where should we teach people about the project, how we do things and what to focus on? Etc. * [quasisec]: No one “rejected” anything, the commit you refer to Nico is here [https://review.coreboot.org/c/flashrom/+/62768%5D(https://review.coreboot.or...) and the issue is the tone of the review. I’ll leave others to judge. * Nico: we need to use mailing list for design discussions, before starting the work * Edward: how to decide what is big and what is small? * **dunning kruger effect** * Nico: early engagement before writing code. * New programmers should be discussed first. * Infra change * Change touching multiple layers * aklm: What happens when the developer has already started? * Threshold to decide whether to send a patch without any prior discussion or conversation: are you ok to re-write the patch if the idea is not supported as is? * Price of the mistake? * quasisec: how to make the price not so high that we don’t scare people away also? * Felix: mention in the guidelines , recommend to discuss on mailing list first * Aklm: this is already recommended on the guidelines * Edward: developers think in code first, they think of design and write some draft code * Nik: whatever tool works best * Felix: An account is needed for Gerrit and thus not everyone is able to join the discussion. * Aklm: for a patch you need to know whom to add as reviewers. On the mailing list, you just post, everyone reads. * quasisec: How to make things like adding programmers a bit more template’ty? Common pattern guidance? Make flashrom API’s better? * Edward: can the code say “file a bug” instead of “write to the mailing list”? * Nico: it could be another mailing list? * Edward: prefix in the subject line, so that people can filter if they want, or not do anything. Create a bug, bug updates are sent on the mailing list. User has a handle on the issue. * Felix: people need an account to create bugs on redmine, but for the mailing list no account is needed.