[prev in list] [next in list] [prev in thread] [next in thread] 

List:       flashrom
Subject:    [flashrom] flashrom dev meeting notes 5.05.22
From:       Felix Singer <felixsinger () posteo ! net>
Date:       2022-05-05 8:59:55
Message-ID: 4e0e9c9636c9c1f103a021c1d7b31aa0524b0621.camel () posteo ! net
[Download RAW message or body]

# 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/UFIVUHNST5K7VJL2OIUFPG3NJWW6WXQZ/
 )). 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](https://doc.coreboot.org/infrastructure/services.html#issue-tracker)
                
    * [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](https://review.coreboot.org/c/flashrom/+/62768)
 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.
_______________________________________________
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-leave@flashrom.org


[prev in list] [next in list] [prev in thread] [next in thread]