Hi, I am following project since few years. Happy coreboot user here.
And I was hesitating but finally I decided to post to the list. Banning core developer for 1 year because of some disagreements sounds a bit harsh to me. Especially that I used to post questions on the IRC channel and mailing list and Nico was the only that actually took my personal struggles building coreboot as well as helped fixing one issue. If not that I would probabbly pass and walk away from actually using coreboot. And now I recommend it to others. Its not defending. I just would like to express my personal experience here. That we are people. We make mistakes. If someone is not behaving maybe the person has some bad-bad day. Some kind of consecuence should be taken. Because without that we wont learn. Am I wrong? Bit still one year ban seems harsh to me. Thats it. Just my 2 cents. Orest, aka AreYouLoco? On October 3, 2024 2:05:12 PM UTC, coreboot-requ...@coreboot.org wrote: >Send coreboot mailing list submissions to > coreboot@coreboot.org > >To subscribe or unsubscribe via email, send a message with subject or >body 'help' to > coreboot-requ...@coreboot.org > >You can reach the person managing the list at > coreboot-ow...@coreboot.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of coreboot digest..." > >Today's Topics: > > 1. Re: Recent disciplinary action taken (Sergii Dmytruk) > 2. Re: Recent disciplinary action taken (Angel Pons) > 3. 2024-10-02 - coreboot Leadership Meeting Minutes > (m...@coreboot.org) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 2 Oct 2024 15:03:42 +0300 >From: Sergii Dmytruk <sergii.dmyt...@3mdeb.com> >Subject: [coreboot] Re: Recent disciplinary action taken >To: Arthur Heymans <art...@aheymans.xyz> >Cc: coreboot@coreboot.org >Message-ID: <Zv02njwrZB-HiR0K@MjU3Nj> >Content-Type: text/plain; charset=utf-8 > >Hi > >I second that. First Nico was banned from flashrom, now from coreboot. >I saw no real basis for the previous decision and see none for this one. >I even thought of him being overly nice in our recent interactions. > >In general, he seems to care much more about the projects than many >others and actually put in the effort. This can result in having strong >opinions and disagreements, but that's not a bad thing. > >Regards, >Sergii > >On Wed, Oct 02, 2024 at 11:55:55AM +0200, Arthur Heymans wrote: >> Hi >> >> I am not happy with this decision. >> We are a community with a lot of passionate individuals that differ in >> their communication style. >> Differences in communication styles cause friction, there is no way around >> it. >> Commenting beyond the mere technical on how we treat each other in a >> community is appropriate and not a violation of respectful conduct. >> To the contrary, sometimes a more heated discussion is to be preferred to >> be being "nice" all the time. >> >> I remember on one of my first patches in 2016, that Nico commented that the >> code looked so bad he wanted to cry. >> It's not "nice" but it was really bad code and I learned a lot since then, >> thanks to the honest and truthful communication of the community. >> More direct communication is preferred by lot of people, including myself. >> >> I believe Nico is a good actor in our community and a 1 year ban does more >> harm than good. >> I personally thoroughly enjoy having him as a reviewer. >> >> I ask the leadership to revisit this decision. Coreboot is a hard project >> to get into and driving the most competent people away is not a smart move. >> >> Arthur >> >> On Wed, Oct 2, 2024 at 9:40 AM David Hendricks via coreboot < >> coreboot@coreboot.org> wrote: >> >> > Dear coreboot community members, >> > >> > Recently there was some unpleasant activity on Gerrit which violated our >> > community’s guidelines regarding respectful conduct. In this case the >> > coreboot leadership team determined that the behavior in question fit a >> > long pattern about which the individual had been previously warned. As a >> > result we have decided to remove Nico from our community for a period of 1 >> > year. We hope this will be a sufficient cooling off period and that we will >> > not need to take more drastic steps in the future. >> > >> > As we've said in the past, we trust that developers in our community are >> > acting in good faith and can generally resolve issues on their own. In >> > cases where two sides cannot reach an agreement, for example in a code >> > review, we expect all engagement to be respectful and to help drive toward >> > a solution. For technical matters this often means starting a mailing list >> > discussion, bringing an issue up during the coreboot leadership meeting, >> > starting a task force to tackle a large problem, or other means of >> > gathering input and collaborating. >> > >> > Personal matters should be brought to the leadership team directly. We'll >> > listen to any complaints or frustrations, but cannot tolerate personal >> > attacks made on Gerrit, the mailing list, or other forums. It is always >> > required that we treat others in a professional manner and communicate with >> > respect, regardless of how strongly we may feel about a particular issue. >> > >> > If anybody feels that a discussion has become too heated, or that somebody >> > is not being treated respectfully, or are simply unsure of how to proceed >> > in a difficult situation, please reach out to the coreboot leadership and >> > we will chart a path forward together. >> > _______________________________________________ >> > coreboot mailing list -- coreboot@coreboot.org >> > To unsubscribe send an email to coreboot-le...@coreboot.org > >------------------------------ > >Message: 2 >Date: Wed, 2 Oct 2024 14:27:00 +0000 >From: Angel Pons <th3fan...@gmail.com> >Subject: [coreboot] Re: Recent disciplinary action taken >To: David Hendricks <dhend...@coreboot.org> >Cc: coreboot@coreboot.org >Message-ID: > <cabqd-o1x8o+v9wgvq34sajwrkws1onqprnhxkb06ra29v8r...@mail.gmail.com> >Content-Type: multipart/alternative; > boundary="0000000000001580ce06237f3ca0" > >Hello list, > >On Wed, Oct 2, 2024 at 7:40 AM David Hendricks via coreboot < >coreboot@coreboot.org> wrote: > >> Dear coreboot community members, >> >> Recently there was some unpleasant activity on Gerrit which violated our >> community’s guidelines regarding respectful conduct. In this case the >> coreboot leadership team determined that the behavior in question fit a >> long pattern about which the individual had been previously warned. As a >> result we have decided to remove Nico from our community for a period of 1 >> year. We hope this will be a sufficient cooling off period and that we will >> not need to take more drastic steps in the future. >> >David, I see you are one of the three members of the leadership team [1]. >Could you please provide the following, privately if necessary? > > - the minutes for the meeting in which the decision was made (which might >contain references to the documents below; if the meeting minutes are not >available, I would like to know why) > - links to the aforementioned "unpleasant activity on Gerrit" > - the guidelines from [2] or [3] (I could not find a document called >"community guidelines") that were violated > >Not knowing what happened nor why makes me afraid to contribute, lest the >same fate befall me as well. Especially considering that Nico has been a >role model for me as I was learning the ropes of firmware development, so >most of the things about coreboot as well as authoring and reviewing >changes I have learned from him. > >> As we've said in the past, we trust that developers in our community are >> acting in good faith and can generally resolve issues on their own. In >> cases where two sides cannot reach an agreement, for example in a code >> review, we expect all engagement to be respectful and to help drive toward >> a solution. For technical matters this often means starting a mailing list >> discussion, bringing an issue up during the coreboot leadership meeting, >> starting a task force to tackle a large problem, or other means of >> gathering input and collaborating. >> >> Personal matters should be brought to the leadership team directly. We'll >> listen to any complaints or frustrations, but cannot tolerate personal >> attacks made on Gerrit, the mailing list, or other forums. It is always >> required that we treat others in a professional manner and communicate with >> respect, regardless of how strongly we may feel about a particular issue. >> >A tiny remark about professional manner: when interacting with others I >know, I like sprinkling a bit of humour in my messages, but without being >disrespectful towards anyone (no dark humour and no making fun of others) >or compromising my knowledge/abilities (do not overdo it and consider that >not everyone might get it). I believe this does not make me unprofessional, >but I am happy to listen in case anyone disagrees. > >Other than that, I agree with the above, but I also believe it is important >to be aware that misunderstandings can and will happen, especially >considering that people from all over the world can contribute, each with >their own culture and tradition. Not everyone is a native English speaker >(even if it does not seem like it, I am not). Not everyone is capable of >noticing when a discussion is getting too heated/tense, let alone do >something to end it before it is too late (I am trying to get better at >this). Not everyone communicates the same way, e.g. autistic people tend to >communicate in direct and literal ways that can be misinterpreted by >non-autistic people [4] (I am autistic, I have had this happen before), >whereas other autistic people have no issues with this communication style. > >I believe that the information in [4] (especially the list of 12 rules) is >valuable and I would appreciate having them integrated into our own >guidelines, although I agree they should be guidelines rather than >strictly-enforced rules: misunderstandings are *still* inevitable and will >happen. In case of a misunderstanding, I think the most sensible way to >proceed is for someone (preferably one of the participants) to notice that >"something feels wrong" and remain calm, disengaging from the discussion if >needed (e.g. wait before replying to an email or review comment). If >possible, try to bring it up without pointing fingers, e.g. "I feel this >discussion is heating up: is there anything I can do to help, or am I >reading into things?" or (quoting a response) "This sounded quite rude to >me, was it intentional?". This requires being able to recognise that >tension is building up and restraining one's impulses; I understand this is >not trivial to accomplish, especially if one is susceptible to getting >angry (e.g. me). > >> If anybody feels that a discussion has become too heated, or that somebody >> is not being treated respectfully, or are simply unsure of how to proceed >> in a difficult situation, please reach out to the coreboot leadership and >> we will chart a path forward together. >> _______________________________________________ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> > >Best regards, >Angel > >[1]: https://www.coreboot.org/leadership.html >[2]: https://doc.coreboot.org/community/code_of_conduct.html >[3]: https://doc.coreboot.org/contributing/gerrit_guidelines.html >[4]: >https://warwick.ac.uk/services/socialinclusion/projects/letstalkaboutdisability/autism/2022_twip_autism_and_communication.pdf >-------------- next part -------------- >A message part incompatible with plain text digests has been removed ... >Name: not available >Type: text/html >Size: 7280 bytes >Desc: not available > >------------------------------ > >Message: 3 >Date: Thu, 03 Oct 2024 14:05:04 +0000 >From: m...@coreboot.org >Subject: [coreboot] 2024-10-02 - coreboot Leadership Meeting Minutes >To: coreboot@coreboot.org >Message-ID: <fbff85ff77887af004c90dc0f73ba...@coreboot.org> >Content-Type: text/plain; charset="utf-8" > ># 2024-10-02 - coreboot Leadership Meeting > > >## Attendees >Felix Held, Alicja Michalska, David Hendricks, Matt DeVillier, Maximilian >Brune, Werner Zeh, Mina >Asante, Martin Roth, Jonathon Murphy, Felix Singer, Julius Werner, Karthik >Ramasubramanian, Jeremy Compostella. > > > >## Announcements & Events > * OCP Global Summit: San Jose, California on October 15–17, 2024 > https://www.opencompute.org/summit/global-summit > > > >## Open Action Items > * 2024-09-18 > * Jon: Schedule a dedicated meeting to discuss the Coverity defects and > action plan. > * Werner: Send out invitations for this meeting. > * Sent out a poll to find a time slot: > https://rallly.co/invite/1c8J3azXAcje > * 2024-05-01 > * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to > translate to Russian (?) > * 2024-01-10 > * Nico:(https://review.coreboot.org/q/topic:enforce_region_api) > * Daniel: Look at how we want to localize (non console) strings for > coreboot. Long term project. > > > > >## Minutes > > > >### [jpmurphy] Have we solicited or received feedback on why organizations >choose not to use coreboot? > * Have we solicited or performed technical analysis of how we compare to > other solutions or what features may be missing? > * David: Were we supposed to set up a meeting to discuss ideas? > * Intel was pushing slimboot - BSD licensed. > * Do we know how much slimboot is used? > * Werner: 2 years ago it was being used because of the license reason. > More than 90% of >contributions were made by intel employees. The main intel contributor has >left the project. It >doesn’t look like there’s a community there at all. No guarantee that the >project will persist if >intel decides to drop it. Based on the BSD license there’s not much of a >chance that a healthy >community will evolve. With intel’s current financial issues, it’s even less >likely. > * Max: I’m not hearing anything about slimboot anymore. > * Martin: Inertia > * Martin: UEFI is more expected, has larger IBVs. > * The silicon vendors push the IBVs - AMI, Insyde, Phoenix. > * ODMs just go with their relationships with the IBVs. > * Developing on your own is hard > * Complexity/inflexibility of FSP. It's hard to justify coreboot + FSP > when FSP requires its own >set of custom patches and hacks to change its default behavior. > * Alicja: I believe we need something that can configure the platform > options at runtime (writing to CMOS/SMMSTORE) instead of setting options at > build time, many people using Chromebooks with Matt's builds complain about > "lack of features". > * Can anyone look further into this? > >### [Werner] Present the workflow for Feature Request and Implementation which >is an outcome of one of the OSFF’s workstreams. > * There are tasks around streamlining feature implementation requests to > make it more plannable for >business use cases. Werner took it as an AI. > Website: > (https://opensourcefirmware.foundation/workstreams/feature-request-flow/) > Specification: > (https://drive.google.com/file/d/1su3s93xNgqy9AixDfHEWGrB_1nxYbQoz/view) > * This process has been reviewed by a number of coreboot and OSFF community > members from a number of companies. > * This would not be required to add a feature, but is intended simply to > help the project and >feature implementers work through the process. > * The point of this is to provide a timeline and a better guarantee that the > feature would be >accepted by the community. > * Felixh: Who is doing the work to implement the feature? > * This is not restricted by the process. Most of the time it would be the > requester. > * Felixh: The “guarantee” of acceptance is very concerning. I’m worried that > companies will demand >that their patches get rubber stamped. > * That’s absolutely not guaranteed by this process. The idea is that a > specification would be >agreed upon, to facilitate the merging of features. The time to reject a >feature is early in this > * Max: Who decides when to transition between phases? > * Werner: It differs between phases. One way is when the community and > requester are in sync. In > the implementation phase if the feature complies with the design > document (this is decided by the implementation team). > There are also suggested timelines. > * Max: There are a number of feature patches where the idea is good, but the > implementation doesn’t fit coreboot well. > How do we avoid merging poor patches? > * Werner: That’s why the community needs to be involved in the > implementation phase. Full features >shouldn’t just be dropped into the tree. > * David: Agreed, even if an implementation isn’t perfect, it may be better > to get it in then fix it >rather than just letting it bitrot. > * FelixH: If things are being done behind closed doors, this process may not > work. > * Martin: Behind closed doors should be a big exception. Let’s see how > this goes. > * Werner: I can look at creating a feature design template from the OSFF. We > can also have a >dashboard of features that are ongoing and what phase they’re in. There are a >lot of things to >improve in the ecosystem. > * Martin: How to give feedback: > * Werner: Send an email or review on the google >[doc](https://docs.google.com/document/d/1zZvnoJwAKX7bm80UxPwnHMfelvoqoYbxR1vAW3xvxuM/edit?usp=sharig). > Feedback is welcome. > >### [jpmurphy] I opened a bug within Google to update our best practices on >bugs being used with coreboot. >There are at least two options, asking for feedback/alternatives: > * 1. Use a public component that everyone can see accessible at > <code>(https://issuetracker.google.com/)</code> > * Some bugs will still need to stay private to protect business needs and > may create the need for secondary bugs. > For this reason, some Googlers prefer we not use this approach. > * 2. Instead of using BUG=b: fields within commit messages, googlers could > use a different ID to >make it more clear it’s a Google bug. Felix S had suggested ChromeOS-Bug-Id. > * Jon: We’re going to try to make the bugs public and update gerrit. Can we > add a rule to link to >the bug? > * Martin will work with the other admins to make this work. > * CrosBug? > * BUG=b:? > * CB-Bug - For coreboot bugs? > * Werner: Please respond to the poll about how to respond to coverity issues. > * (https://rallly.co/invite/1c8J3azXAcje) > >### David: We had to take an action with a community member’s behavior. >Details are on the mailing >list. David will respond to various questions on the mailing list. > * If anyone is feeling anxiety about dealing with other people in the > community, *please* reach >out. You can email anyone on the leadership team or the arbitration team. >These issues will be kept confidential. >(https://coreboot.org/leadership.html) > >### Granite rapids patches are out! Great job getting these out before the >chip is out. > * FelixH: These are great and very appreciated. It’s obvious that a lot of > work went into trying to improve things. > > > > ># Next Leadership Meeting > * October 16, 2024. > * [coreboot Calendar](https://coreboot.org/calendar.html). > > > ># Notice > * Decisions shown here are not necessarily final, and are based >on the current information available. If there are questions or comments >about decisions made, or additional information to present, please put >it on the leadership meeting agenda and show up if possible to discuss it. >Of course items may also be discussed on the mailing list, but as it's >difficult to interpret tone over email, controversial topics frequently >do not have good progress in those discussions. For particularly >difficult issues, it may be best to try to schedule another meeting. > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >coreboot mailing list -- coreboot@coreboot.org >To unsubscribe send an email to coreboot-le...@coreboot.org > > >------------------------------ > >End of coreboot Digest, Vol 236, Issue 1 >****************************************
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
