• OfficeHours

Office Hours for the GNU Toolchain

Join our office hours and meet GNU Toolchain developers!

Everyone in the community is invited to attend the office hours.

The intent of office hours is give a regular opportunity for the community to meet virtually, ask questions, present talks, and socialize.

The office hours are covered under the GCC Code of Conduct.

We use Big Blue Button to run the meeting. If this is the first time you are attending please give yourself time to setup an account and test your connection.

The current plan is to have Office Hours every Last Thursday of the Month at 11am EST5EDT.

You can convert this meeting time to your local time like this: `date --date='TZ="EST5EDT" 2024-04-25 11:00'`

Meeting Link:

• https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

Room Admins

The following people are currently room admins (alphabetical):

• Carlos O'Donell
• David Edelsohn
• David Malcolm
• Guinevere Larsen
• Jason Merrill

A room admin must be present to start the meeting, and can promote viewers to temporary room admins.

Room admins can delegate presentation and whiteboard access (right click on viewer's name to access context menu).

Next Meeting: 2024-07-25 @ 1100h EST5EDT

Agenda:

• Please add your agenda items here by editing the wiki page. If an agenda item requires a specific person to attend, please reach out them and ask them to attend the Office Hours.

Meeting: 2024-06-27 @ 1100h EST5EDT

Agenda:

• Please add your agenda items here by editing the wiki page. If an agenda item requires a specific person to attend, please reach out them and ask them to attend the Office Hours.
• DCO for GDB? (raised on the list already but what can help this issue along?) (Andrew Pinski; might not be able to attend)

Notes: ​ * Joel Broebecker was in favour.

• Tom Tromey was in favour.
• Eli Zaretski not in favour
• Lancelot: Everything we do is opensource and we publish that on github.
• The push is to accept contributions to our downstream ports.
• The end goal is to send everything upstream.
• The question we have in the current framework if we accept contributions from someone on github, then we can't send it upstream.
• We don't want to be stuck with downstream changes that we can't send upstream.
• Carlos: Conceptually DCO is designed to solve this problem.
• David: What is the exact question?
• Lancelot: The downstream doesn't own the copyright.
• David: What is the license you received the contribution under?
• Lancelot: That is also unclear.
• Lancelot: We would have to collect contributions from that developer?
• Carlos: Upstream gdb can decide to accept works that they don't own the copryight to.
• Lancelot: gdb upstream requires copyright assignment.

• Carlos: gdb contribution checklist? https://sourceware.org/gdb/wiki/ContributionChecklist

• Lancelot: Yes, item 6 FSF copyright assignment.
• Carlos: I agree with David Edelsohn's position that the gdb maintainers can make a choice to accept without copyright assignment.

• Thiago noted: https://inbox.sourceware.org/binutils/86jzinqr4h.fsf@gnu.org/

• Carlos: The right to submit is something the contributor has to certify, what Eli is asking for is something that Andrew can certify with his employer.
• Thiago: There are real and meaningful issues that need to be addressed when copyright assignment is addressed.

• Carlos: That is not the right framing IMO, it is the same framing as ChangeLog's make our code better. You have to choose to accept the risk and the benefits that brings.

• Carlos: BFD should have DCOd code? We have the same problem in reverse with glibc that we have gnulib as canonical for our copies of gnulib code and that still requires copyright assignment.
• Lancelot: Yes, we use code from bfd and libiberty (gcc)
• Peter: We also use libffi in gcc. But that's got lots of problems for integration.
• Carlos: But gcc includes libffi and the sanitizers and neither of them use copyright assignment.
• Peter: Yes, neither has copyright assigned.
• Lancelot: Yes, the downside is that you can't relicense.
• Carlos: Risk mitigation, and a problem that may happen in the future. It is a tradeoff to make.
• Peter: Missed Maxim's talk about CI
• Maxim: I will add the recordings to the meeting minutes.
• Peter: What about talks at Cauldron?

• Carlos: You can register them right now? https://gcc.gnu.org/wiki/cauldron2024 says we accept talks by email.

• Thiago: Eli quoted a gnu-prod-discuss thread but the mailing list is private?
• Carlos: Yes, unfortunately, and to my personal disappointment, the list is private for GNU Maintainers to discuss issues. I think it should be public. Please ask for the conversation to be made public.
• Maxim: Added links to the recording.

Meeting: 2024-05-30 @ 1100h EST5EDT

Unfortunately the audio in the meeting room was unusably choppy, so we moved the meeting to https://meet.google.com/dko-gimi-azq?pli=1

• Maxim Kuvyrkov presented about Linaro CI: https://drive.google.com/file/d/16gBSsFwGhRrAvEIAmaSU3PCB_Ub9R9I5/view

  • Linaro Connect presentations on the same topic: https://youtu.be/MTtJMU7-8Oc?si=78waikNFKp7Mbkxh and https://youtu.be/rlKhVgQjcHM?si=yE72F8xDW2nBntWG

• Questions were asked by the participants and the identified issues around patch revert policy were discussed.
• Maxim noted that he will raise revert policy discussions upstream.

Meeting: 2024-04-25 @ 1100h EST5EDT

Agenda:

• Please add your agenda items here by editing the wiki page. If an agenda item requires a specific person to attend, please reach out them and ask them to attend the Office Hours.

Meeting: 2024-04-25 @ 1100h EST5EDT Agenda:

• Thiago: Anything to wrap up about submitting generated files along with the patches?
• Carlos: Is there a particular project you would like to see this become standard?
• Thiago: My understanding is that glibc and gdb submit with autogenerated files along with the patch. Not sure about gcc (has a decision made about that).
• Carlos: Jason says his mic is not working.
• Thomas: I'd be in favour of submitting complete patches corresponding to what you would push.
• Carlos: So git format-patch and just send it to the list.
• Thomas: When you upgrade to the next autoconf version then maybe you would do that differently.

• Siddhesh did hte update from 2.69 to 2.71. https://inbox.sourceware.org/libc-alpha/20230717142150.185969-1-siddhesh@sourceware.org/ which included the whole patch.

• Tobias: When do you update?
• Carlos: When you can.

• Note: Jonathan Wakely for Fedora has a custom COPR repo with automake and autoconf at the right version for doing upstream development https://copr.fedorainfracloud.org/coprs/jwakely/autotools-gcc/

• Carlos: Jason, David, David --- Was there a conclusion on the post what you commit discussion for gcc?
  • Jason: there seemed to be general support for posting everything
• Tobias: The advantage of posting everything then some others can try it without others running the scripts.
• Thiago: I saw maintainers chime in and say they agree.

• Update this https://gcc.gnu.org/contribute.html

• Thomas: Discussion about Cauldron dates on IRC.
• Doesn't seem like anyone has anything more conclusive.

• Carlos: I know that LPC and Cauldron are both very similar time wise and so a Prague -> Vienna travel would make it easier.

• Tobias: The Fri, 13th to Sun, 15th is what they wrote. And LPC is 18-20 in Vienna.
• Richard: The very first Cauldron were hosted by Google, but those were strictly two day events.

• Carlos: Posted https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650029.html, but I empower Thiago to have done exactly the same thing.

Excerpt from online text chat:

• Jason Merrill, 11:33 AM
  • any thoughts on enabling a pull-request workflow (via gerrit or otherwise)?
• Claudio Bantaloukas, 11:39 AM
  • Jason, I've been looking at this and Samba have an interesting workflow, where they have a gitlab instance where people who are used to forges provide patches and get CI. The merge requests never get merged directly, they are discussed in the mailing list by volunteer contributors that sheperd the patch. This would allow for both workflows to coexist.

  • See https://lwn.net/Articles/868374/

• Thomas Schwinge, 11:41 AM
  • Claudio, that's interesting! I'd be in favor of exploring such a thing.
• Claudio Bantaloukas, 11:42 AM

  • Overseers mentioned that a forge installation should not be ruled out, it might not be gitlab though. Let them know I guess

• Followed by a quick verbal discussion of the GCC/Rust usage of GitHub: newcomer-friendly, "random" new contributors every other week, CI for every Pull Request, on GitHub for staying close with the Rust project, etc.

Meeting: 2024-03-28 @ 1100h EST5EDT

Agenda:

• Please add your agenda items here by editing the wiki page. If an agenda item requires a specific person to attend, please reach out them and ask them to attend the Office Hours.

• [ChristopheLyon] Update on precommit-CI and maintainer-mode. I started a discussion on the lists with a proposal to help automatically regenerate files after applying a patch. Not convincing so far, another possibility would be to change the patch submission policy to include all regenerated files when submitting a patch for review.

  • motivation: enable precommit CI to process more types of patches, thus increasing it's coverage/usefulness. Patches submissions do not include autogenerated files (from autotools, but not only). On several occasions we could not test patches for aarch64 binutils for instance, because they required an update to opcodes/. A few people also complained after receiving a regression notification because their changes to autotools files were not handled.
  • relying on maintainer-mode means we have to run configure to create the Makefiles, but for target libraries this means we have to build all-gcc first. And we want to run this step at -j1 because the current Makefiles have race conditions, so it would take a very long time
  • we can add a script to update things as needed, without configuring if possible. Similar to autoregen.py (which should probably be imported in contrib/) , OK for autotools and simple updates (eg. fixincludes). What about more complex ones (eg libgfortran, tm.texi / tm.texi.in, or opcodes in binutils-gdb)?
  • how do we make sure such a script is kept in sync with Makefiles?
• [jason] I think changing the policy to include regenerated files is the simplest solution
• Agreed that having Christophe email the release managers and the developer community to request that the policy should be changed to include regenerated files to make the CI systems not need to redo work that developers have already done.
• [carlos] It also allows reviewers to make sure the generated files are correct.
• [dmalcolm] Can we get dejagnu failures to zero? Sorry for failures I've introduced.
• [maxim] While we can strive for zero failures. We should make sure our xfail list is up to date. But even keeping the xfail list updated would take an FTE to manage. So we have automated flaky tests and failure detection. Our goal is now flaky tests trending down to zero. Then try to trend down number of failed tests.
• [dmalcolm] I think some colleagues of ours have created a tool called bunsen.
• [dmalcolm] How do I get started building with a cross-compiler?
• [carlos] glibc/scripts/build-many-glibcs.py ?
• [maxim] qemu user mode emulation?
• [carlos] board file for user mode qemu?
• Discussion on pre-commit CI about how it could work with the toolchain.
• Maxim could give a presentation in 2 meetings so Peter Bergner can attend.
• Next meeting: April 25th 2024.

Meeting: 2024-02-29 @ 1100h EST5EDT

Agenda:

• Please add your agenda items here by editing the wiki page. If an agenda item requires a specific person to attend, please reach out them and ask them to attend the Office Hours.

• [Tobias] Using a different tool than BBB.linuxfoundation.org that either permits to join without creating an account or has a "forget password" function and actually has also some support/contact possibility → Found the right contact at Linuxfoundation (LF Jira IT-26402); they now know how to do it manually (short-term solution). Real solution seem to be to upgrade Greenlight Dashboard, which involves re-creating all the rooms and may happen down the line.

  • [codonell] I can confirm that this is the case. LF IT is talking to the provider about upgrading to Greenlight Dashboard. This came up in the CTI TAC meeting: https://lore.kernel.org/cti-tac/6b433955-2865-232a-44c0-59682cbac446@redhat.com/T/#u

• [Tobias] FOSDEM recap.
• Carlos: I wanted to highlight the success of Maxim Kuvyrkov's idea to create a patch reviewer pool from which we can pick reviewers and review patches in the incoming queue of things to review for glibc. The delegation of review has been successful in reviewing difficult to review patches.
  • Maxim: It also reduces the bus factor for reviewers since the selection of reviewer from the pool is random.
• Tobias: Had problems connecting before but created a new password with a new account.
  • AI: Tobias to add LF IT jira project for filling a ticket.
  • Carlos: Yes, upgrading to greenlight v3 is the fix, but few have done the migration yet and it appears to involve manual account migration.

• GCC devroom at FOSDEM: https://fosdem.org/2024/schedule/track/gcc/

+ videos (for the room, i.e. not only GCC): https://video.fosdem.org/2024/k4201/

• Thomas: FOSDEM presentations were great and it was a big success.
  • From the begginning the room was full, at 70-80 people.
  • Settled on ~100 people.
  • Will send a short report to the gcc mailing list.
  • Close out the topic for this year.
  • David and I agreed that we would do it again next year.
  • Tobias: Happy that the room was relatively large.
  • Most people stayed for the whole time. Some people went in and out.
  • Some were off the main tracks but still interesting.
  • More submissions than we had time to handle.
  • Thomas: We might invite people to present here.
  • Carlos: What would we do differently next year?
  • Thomas: I doubt we would get a full day workshop.
    • It might not be possible to fill a full day workshop.
    • Depends on the submissions.
    • Keep it half day.
    • Carlos: Can we immediately queue talks we don't accept to the office hours?

    • Thomas: Q&A was taken from presentation time and scheduling talks back to back were harder.

    • Pierrick: First FOSDEM. Thank you Thomas. I was a bit stressed, I wasn't expecting as many people, around 100, and I enjoyed the experience.
    • Tobias: The live online streaming was nice. Matrix questions from online were few, but good quetions.
    • Carlos: Who was assigned to watch Matrix?
    • Thomas: Yes, need someone to do that. Make sure video and audio was working (thanks again Dodji Seketeli!) and monitored the online chat channel. We had to get a spammer in the channel removed by FOSDEM admin.
    • Thomas: Even though FOSDEM has switched to in-person you can do some remote and it is hard to do the remote part well.
    • Tobias: Remote people could ask questions directly in Prague GNU Tools Caudlron.
    • Richard: Yes, we decided Cauldron would not be streamed live early on. Not for technical reasons but just logistical, and to simplify things.

    • Carlos: We need to run the SOP for Cauldron and figure out the conference logistics e.g. https://gcc.gnu.org/wiki/CauldronSOP

• Siddhesh: In the mold talk there was a discussion of donating mold to binutils.
  • That is an interesting prospect.
  • Tobias: I reached out to Nick about this, and I need to reach out again to Rui.
  • Siddhesh: It's C++ so we have to ask what happens in the future. Will we get new maintainers?
  • Richard: The biggest problem with gold is that it was ELF only without linker scripts, and this targets only a subset of our userbase.
  • David Edelsohn: I can give some context. It is using C++, but not gratuitous (C++20) and it uses C++ to support architecture with a minimal amount of code (high maintainability). Rui is willing to work and expand targetting other architectures. Rui is looking at the embedded community and trying understand the gaps. Support for a subset of linker scripts that provide equivalent functionality. Mold supports the gcc plugins, so it is a fairly complete solution in this space.
  • Tobias: The offloading support in gcc now works with mold.
  • Edelsohn: There is a lot of opportunity to have mold compliment binutils.
  • Siddhesh: I'm positive of endorsing mold and I'd like to see it contributed to binutils.
  • Carlos: It would be interesting to support linkers that provide workload specific support.
• Adhemerval: What do we do with the current glibc buildbot failures? Is anyone looking at the results? Should we work more closely with the buildbots?
  • Carlos: Volunteers spend their time on the work that meets their requirements. I am focused right now on pre-commit CI because it has the highest value.
  • Maxim: Post commit-CI allows you to test many more configurations.

  • Carlos: https://bodhi.fedoraproject.org/updates/FEDORA-2024-af6d70c08c

  • Carlos: We have post-commit CD in Fedora, but it is configuration specific.
  • Christophe Lyon: I started a discussion about pre-commit CI and ran into trouble about maintainer mode.
  • Richard: We have a lot of questions about our process for pre-commit CI.

Meeting: 2024-01-25 @ 1100h EST5EDT

Agenda:

• [dmalcolm] Would anyone else be up for having occasional short/lightning talk-style presentation in these office hours? (the intent section at the top of this page does include "present talks")
  • [tschwinge] Either during the Office Hours, or would we like to set up a separate "webinar"-style series (no fixed schedule) for such presentations, with wider (external) publication/advertizement than the (internal) Office Hours?

  • The specific case here is a GSoC/GCC 2023 student, who wanted to present his work at the FOSDEM 2024 GCC devroom, but can't travel due to visa issues.

  • [codonell] I am for a 30m lightning talk at the start of the office hours, and promoting that specifically on a variety of channels.

Meeting: 2024-01-25 @ 1100h EST5EDT

• Carlos: Sending my regrets. I have a family conflict starting at 1030am, but I'll try to catch the tail end of the office hours.
• Carlos: I'll make sure one of the BBB admins is present and can admit people to the room.
• Carlos: Jason Merrill has a conflict and can't make the meeting this week and sends his regrets.
• Talks in these Office Hours?
  • Or do we reuse this room, but not the office hours?
  • Perhaps a separate webinar session?
  • OK to use this slot if we don't take the whole slot; e.g. one 15 minute talk per month?
  • ACTION: dmalcolm to reach out to people unable to make it to FOSDEM to see if they'd be up for giving a talk here
  • We'd want to record the presentation (if the presenter consents)
  • ACTION (Carlos): Figure out how the recording option will work and how we publish to Peertube.

  • Note: Ian Kelling says the FSF uses Framasoft's Peertube instance https://framatube.org/.

  • Richard: Should we be looking at publishing the GNU Tools Cauldron videos on Peertub?
  • Carlos: Yes, we should look at improving the accessibility of what and where we publish for our FOSS community.

• Looking forward to the FOSDEM 2024 GCC devroom, <https://fosdem.org/2024/schedule/track/gcc/>.

• Thomas Schwinge gave a short overview of what's happening with GNU Toolchain Developers moving from Siemens/Mentor Graphics/CodeSourcery to BayLibre (or elsewhere). Talk to him of other people with @baylibre.com email addresses for details.

• Machine learning and AI-generated code in GNU tools???
  • What happens if someone submits a large chunk of AI-generated code to a GNU toolchain project?
  • What about an AI model? e.g. an optimization in GCC. What does "freedom" mean here: are you providing the ability for people to modify the model?
  • Ian Kelling: The FSF License team is looking at what it would take to have a public position on this for the FOSS projects that are supported by the FSF.
  • David Edelsohn: It would be really difficult here if this had to be done on a case-by-case basis.
  • Another aspect of this is based on legal precedent and that will vary by region and country.
  • The precedent in the US is that AI generated work WITH human input could be copyrightable and therefore assignable.

• dmalcolm: chatted about https://gcc.gnu.org/wiki/libdiagnostics

• When is next meeting?
  • wiki says "every 4th Thursday of the Month"
  • but Carlos has it set up as last Thursday in month
  • Going with last Thursday in month; ACTION (Carlos): edit wiki page (done)

Cancelled Meeting: 2023-12-28 @ 1100h EST5EDT

No scheduled office hours for December 2023.

Meeting: 2023-11-30 @ 1100h EST5EDT

Agenda:

• Date for this meeting is in flux and has to be decided.
  • Thomas Schwinge asked for it not to be on Wednesday.
  • Carlos suggests 4th Thursday of the Month.
• FOSDEM presence [dmalcolm]
• Please add your agenda items here by editing the wiki page. If an agenda item requires a specific person to attend, please reach out them and ask them to attend the Office Hours.

Meeting: 2023-11-30 @ 1100h EST5EDT

• Agenda Item: Date of the office hours?
• Carlos: Does the Thursday meeting work for you Thomas?
• Thomas: It works yes, but I'm just one person.
• Carlos: I'll schedule out 4th Thursday for the rest of the year to have the office hours scheduled out.
• Agenda Item: FOSDEM presence
• David Malcolm: Who else has a devroom?
• I see 3 proposals to the gcc dev room?
• gdb has a dev room.
• There is a binary tools dev room which has some overlap.
• Thomas: I can't login to see what is proposed.
• Dmalcolm: I raised the issue that Thomas needs access.
• Carlos: I think that we should keep plugging away at the conference and ensure that we make the process for supporting and having devrooms at FOSDEM smoother.
• Thomas: It has not been a smooth process, that I can't access the submissions, or the work with the GNU Toolchain fund process.
• Carlos: I'm sorry the process has not been the smoothest and we'll keep working to document what we need and how to make it run smoothly.
• Carlos: I would like to know the exact dates on the devroom deadlines?
• DavidM: A Web UI does the track organization and there might be a date that locks that out.
• Carlos drafted the GNU Toolchain Fund process docs:

  • https://gcc.gnu.org/wiki/GNUToolchainFund

• DavidM: Sent email to Thomas to review should allow him access to review the proposals.
• Carlos: Would Thomas have had access if he was in from the beginning?
• DavidM: Maybe. Since the systems have changed, and the migration may have caused problems.
• That's the end of the agenda items.
• Sandra Loosemore: Deprecation of nios2 across the whole toolchain?
• DavidE: Are you suggesting deprecation or proposing it?
• Sandra Loosemore: I am gcc/binutils maintainer and must resign.
• Joseph Myers: For Linux kernel architecture deprecation, talk to Arnd Bergmann as well.
• Sandra Loosemore: and intel is eol'ing the architecture
• Nick: Andrew in Nios2 also is maintaining it in binutils.
• DavidE: If Intel is EOL-ing the architecture then go directly to add the deprecation.
• Richard: We can't force anyone to be a maintainer longer than they want to. They remove their names from the MAINTAINERs.
• Richard: It would be unusual for a port to be deprecated while the port is in use.
• Carlos: So you just remove your names via patch?
• Richard: For GCC14 release notes we say there are no maintainers and it will be deprecated in GCC15 if nobody steps up.
• Joseph: As I said in the chat contact Arnd Bergman to remove the Linux support.
• Joseph: This is more like the removal of tilegx and tilepro where an ehtusiasts community likely doesn't exist.
• Carlos: Anyone still using SH?
• Thomas: Yes, the gccrs work came across them because they were doing some work for their hardware simulator.
• Peter Bergner: You need to mark it deprecated because that way the configure triggers the warning.
• Siddhesh: If the port continues to build then the maintainer overhead isn't there. Like the deprecation of ia64.
• Tobias: Mark it unmaintained without deprecation?
• Richard: There is an obvious ordering here.
• Carlos: Richard do you have a suggested ordering?
• Richard: NEWS entries for all packages that it is unmaintained. Then next release deprecated.
• Peter Bergner: If we say that then it could be 3 years away?
• Siddhesh: Do we use gcc-announce?
• DavidE: People may treat architecture notices like this as spam so I'm hesitant to use the list for that.
• Peter Bergner: Mark it deprecated proactively so we shorten the cycle?
• Sandra: I'd rather deprecate it now.
• Carlos: Did we answer your question?
• Sandra: I'll work it out offline.
• Richard E: On the topic of deprecation can we get rid of nested functions?
• Joseph: The kernel supports building with clang so it can't use nested functions.
• Carlos: Other languages use the nested functions.
• Richard E: Trampolines on the stack and cache cleaning doesn't work well or works poorly.
• DavidE: Any package that can build with clang that doesn't support it isn't using it, and it's a function of the ABI/ISA what is needed for nested functions.
• Siddhesh: In Fedora 40 Nick is proposing to make executable stacks an error. Can we use that to weed out all nested functions in C?
• DavidE: Is the implied question about security hardening? Disable this as a default extension? OpenSSF Compiler Hardening guide could have another option here for this? New option or default behaviour? The better issue is how to express to users that they are using a risky feature?
• Joseph: We have some user options for Ada nested functions, extending them to support more cases, and C developers could use those options without the trampoline use.
• Siddhesh: That's not the direction that I would like to go in because "safer ways to use tramplines" is not a good direction.
• Joseph: I don't like the nested functions to C, but if people really want to use netsted functions they can be used more securely.
• Carlos: Does Marek's -fhardened mention this?
• Siddhesh: Maybe gcc15 could mention removal of flags.
• Jason: Do we need to wait for gcc15?
• Siddhesh: Oh, I thought we were blocked from that after stage1?
• Jason: The option can be tweaked.
• Tobias: If taking an address is the problem then we could hide that behind an option?
• Joseph: It's taking the address and then using it as a non-nested function that requires a trampoline.
• DavidM: Can I ask a question about nested functions?
• DavidM: The analyzer completely fails to handle them.

  • https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106441

• DavidM: Can I just give up if I see one?
• RichardE: Yes, if we deprecate them then it's a good reason to ignore them.
• RichardE: The non-local-gotos are really bad when you have shadow stacks. There are a number of gotchas here that don't mesh well with modern security hardening.

Meeting Link:

• https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

Meeting: 2023-10-17 @ 1100h EST5EDT

Agenda:

• First official Office Hours and test of the system.
• No specific agenda will be presented, but feel free to attend.
• Carlos to check that Firefox client video is working based on TURN enablement for BBB.
  • Provide feedback to LF IT given previous meeting results.

Meeting Link:

• https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

Attendance: 11 attendees

Notes:

• Welcome to our first office hours!
• How often should we hold office hours?
• What would you like to see in subsequent office hours?
• Would you volunteer to lead one of the office hours?
• Thomas - Should we expand this to interns or new developers?
• David E - I didn't expand this out new developers or others yet because this was a test of the infrastructure. A GSOC student was asking about David M's tutorial presented again. How often depends on how useful this becomes? Bring in release managers?
• David M - Monthly works well. Nice to see everyone and not wait a year. If someone turns up and wants a tutorial I'm happy to give it. Something I learned in the tutorial session is that there was a lot of gcc I didn't know, and the mix of developers new and old, created useful feedback.
• David M - Our presence at FOSDEM I'd like to talk about.
• Jason - I see these are primarly informal. No need to have a presentation lined up.

• Carlos - Moderators can start the room for impromptu conversations. Moderators are listed here and we can add more: https://gcc.gnu.org/wiki/OfficeHours

• David E - We can create other rooms, but a breakout room in the office hours can be created.
• David M - I look forward to the day when scheduling becomes an issue.
• Richard E - What do we want to do about topic areas? Basic watercooler? Control of patch review? Training and tutorials?
• David E - There are also non-technical meetings about a large number of topics. Steering committee and stewards take a hands off role, but we want to have a more open conversation about that governance.
• Carlos - Could we schedule 30m of the Office hours? Some structure?
• David E - People could propose the event or agenda? Do people have any questions? Asking here where the audience is smaller.
• David M - FOSDEM! Deadline for proposing a developer room was yesterday. Various people have proposed a Binary Tools Devroom and Debugger and Analysis tools room (Jose, Gwen, Dodji). It would be nice to have a co-proposer to the Developer room for 1 day, 8 hours of material for gcc. Looked at what LLVM did for their devroom, and put out a call to do lightning talks. Shoudl we have enough context?
• Carlos - Ping Arjun Shakar to talk about glibc for FOSDEM?
• Lancelot - Are we going to merge the devrooms if they are not all accepted?
• Thomas - I plan to be at FOSDEM, and please include me as a co-presenter. LLVM this year had a half day devroom (not a full day). Could start with a half day if that works.
• David M - Yes, login and try to set yourself up as a co-presenter?
• Thomas - I'll register after the call and let you know the details.
• David M - Random question, who is Lancelot Six?
• Thomas - GDB developer working on AMD GPU support?
• David E - Thanks again David M and Thomas for organizing this.
• Carlos - Yeah, there is so much to contribute to in FOSS that we do need to advocate for our projects and support new developers.
• David M - After stage 1 I want to turn my tutorial into a real committed tutorial.
• Thomas - At Cauldron we had 4 students (2 GSOC). We might ask them to present at FOSDEM?
• David E - We have many different stove pipes. GNU Tools Cauldron CIC. GNU Toolchain Fund. Steering Committee / Stewards in the community (official GNU Maintainers for their project). Sourceware Project at SFC. Core Toolchain Infrastructure Project (LF/OpenSSF). Company sponsorship?
• Richard E - Can we have a top-level description of funding?
• David E - Yes, we will try to setup a website.
• Carlos - We have been the most successful with the GNU Toolchain Working Together Fund to fund student travel to GNU Tools Cauldron.
• Thomas - If we keep the GSOC students in the community that helps.
• Carlos - I think you should email David E, Joel B. and myself to request funding for FOSDEM students going to do work.
• Sudakshina - What are we doing with the office hours? What is the aim of this office hours?
• David E - It can be just open hours for questions. I want to be flexible.
• Thomas - One concrete thing would be to have a wiki page with agenda.
• David E - Carlos' proposal for once a month would be good.
• Jason - I had just been about to suggest what Thomas said, just use the wiki to gather agenda items.
• Richard E - How does this meeting look like the glibc patch queue review.
• Carlos - Patch queue review is totally different from this.
• Richard E - Do we need patch queue review?
• David E - You asked two questions. Do we need or do we want?
• David E - We need to get the buy in from people who can review the patches?
• Jason - The problem with doing that for gcc, is how large it is.
• Jason - The success of "please review my patch" depends on the success of finding a person to review that patch.
• David M - As I understand it glibc is 2 levels ahead, automated patch tracking that works.
• Richard E - Partly our workflow. Partly a limitation of patchwork. Revised patches don't get linked together.
• Sudakshina - Part of this is about intentionality. The intention of doing that as a community.
• Jakub - We need to get the tooling to follow our workflow. Should really ask Richie since he reviews a lot of patches.
• Carlos - Agreed completely that patch review is about intentionality and that even if Jakub just shared a view of his inbox every week and talked about patches that need review that would help keep people focused on the backlog.

Internal Test: 2023-10-11 @ 1100h EST5EDT

Agenda:

• Infrastructure test by various developers.
• Check for logins.

Meeting Link:

• https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

Notes:

• Carlos sent emails to LF IT to add several attendees as admins to open the room.
• Reviewed some of the video issues that we were having with attendees.
  • Sent email to LF IT to ask about TURN server
  • LF IT has worked with BBB provider and turned on TURN for FF clients.
  • LF IT has requested we check this again. I said we'd test on October 17th.