# 21th April 2022, 6:00 - 7:00 am UTC+0
Attendees: Thomas, David, Edward, Nico, Anastasia, Nikolai
## Decisions Summary
* Anastasia will be doing next release. She has never done release
before, and needs help from more experienced people.
## Agenda
* [FelixS] Redmine is ready to use
* If you wonder, new registrations require an unlock by an
administrator. This is to prevent spamming and bots. Maybe we can work
out something better in the future.
* I added additional fields to issues, so that important
information is easily visible. For example affected hardware, affected
OS, affected version. Please tell me if you find these useful or if you
need other fields, trackers, ..
* aklm: let’s start using, I will try to create an account and see
how it goes
* [FelixS] Created a proposal for closing GitHub issues and pull
requests automatically
* Closes newly created issues and pull requests and adds a comment
using GitHub Actions hook. Old issues and pull requests stay untouched.
* [flashrom patch](https://review.coreboot.org/c/flashrom/+/63671),
based on GitHub Actions hook and [repo-
lockdown](https://github.com/dessant/repo-lockdown).
* My playground
[https://github.com/felixsinger/awesome-repo](https://github.com/felixsinger/awesome-repo)
* [Nico] ChromeOS fork and attempted convergence
* (in case witnesses of that time are present) What led to the
fork?
* [PatrickG] Velocity requirements: stuff needed to happen to
make progress on the products using flashrom and it didn’t happen in
time. Not much of a problem when it’s temporary but stuff just piled up
over time.
* Nico: lots of things went wrong. And it took around 8 months
to converge
* David: Fork happened when Carl-Daniel was the maintainer, and
he was really busy. Tools were worse that time.
* We had irreconcilable differences at that time
* Edward: Stefan asked me to unfork flashrom. I had to work out
how things were done, how to re-write parts of the system. It was just
me, on my own, no other resources. I took upstream and tried to make
chrome os work with upstream. Except for a few patches: mapping hack
inside of sb600spi, I am trying to chase AMD to get documentation , so
that I can improve it.
* David: Timer stuff I was trying to deal locally. There were a
bunch of things that had to be dealt locally.
* David: It was uglier downstream than it should have been.
Trying to minimize the number of hacks. There are things that can be tr
* Edward: Where we are today: I was trying to have a team for
flashrom, to spend dedicated time to work on flashrom. We had good
results on that, but it takes time. Hard to allocate people.
* (in case somebody knows) What is Google’s current strategy to
avoid repeating mistakes of the past?
* [PatrickG] Generally CrOS is willing to go upstream-first (as
with coreboot) after divergence has been resolved. Depends on the
upstream, so probably need to work on the questions raised by Edward et
al.
* [Nico] Upstream-first of a dominant vendor made it harder
for others to work upstream on coreboot. It’s not what I had in mind,
but this would be repeating a mistake, IMHO.
* Nico: There were very good and very bad contributions
during last years
* Edward: how do you quantify that nothing is happening?
* Nico : sb600 is bricking machines , but nothing is
happening
* Edward: maybe it is a visibility problem, also some
things are really hard
* Nico: maybe devs in google need to talk to each other?
* Edward: original patch came from AMD, not from google
* Nico: if it takes a long time to find a solution, maybe
just revert?
* Edward: we didn’t know it would take so long
* David: board bringup. There is 3-4 months time before
chromebooks get into users hands, and then bugs get filed. Bugs in the
code which is 6 months old, but people are already reassigned to other
tasks.
* Edward: maybe have a parameter which turns on the
behaviour, default is turned off. The problem exists, but it is not
trivial.
* Nico: The problem with the “upstream-first” idea: when
something is not trivial, you push it upstream first, and then try to
figure out how to fix it.
* Edward: that was exceptional situation, it is better now
* Nico: most of the issues in the list are from google.
When someone looks at the code, it is clear that code it is not
understood.
* Edward: we opened issues about non-documented programmer,
and added documentation
* Nico: one of the drivers is mixing all layers of
flashrom.
* Nikolai: what are concerns with the code? We will try to
remove them.
* Edward: The datasheet was in mandarin, and lots of
questions were discussed in mandarin with the vendor. Vendors were not
giving documentation, despite us asking them many times.
* Nico: Who is doing reviews for google? We need reviewers
who know all layers of flashrom.
* David: Can we simplify the process of adding a new
chipset? So that it would be easier to contribute without introducing
bugs?
* Thomas: It would be nice to have more structure in the
code repository. It is hard to understand where the code needs to go.
Having a specific place for every component is a good idea
* David : flash.h and flashrom.c are dumping grounds
* Anastasia: Nico do you think it is possible so that we
all work together normally and peacefully? If we resolve issues from
the past, and also write guidelines so that new issues won’t appear and
development goes normally? >> Yes it is possible.
* Let's make a release!
* Nico: I spent a lot of time on this already, I can’t
spend even more time. Anyone else?
* Nikolai: What if the vendor does not give documentation,
do you think it’s better to have a driver which is not documented, or
no driver at all?
* David: for early chromebooks , drivers were not
documented. That’s why an option was called “I want brick”
* Edward: some of the changes in the chromium tree we are
not sending upstream, because there is no documentation
* Nikolai: Can we have a flag for situations like sb600spi
? Finer granularity than the whole driver. Feature flags?
* Nico: other people work on the sb600spi code, affects
everyone who works on the code.
* Edward: something similar in kernel hardware quark
framework.
* Nico: this needs documentation, whatever is needed to
understand the quark. Man pages are for the users, but there also
should be documentation for developers. In what product is this chip?
You can document what you know
* [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 on 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.
* [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.
* Anastasia: We currently have more GSOC project proposals than mentors
(5 vs 3). If someone wants to be a mentor, it is not too late. Contact
Anastasia or Felix.
_______________________________________________
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
