-
Notifications
You must be signed in to change notification settings - Fork 1.5k
MSVC STL Contributors Meeting Notes
mnatsuhara edited this page Jul 28, 2020
·
10 revisions
We are currently working on determining the best format, frequency, and method for determining agenda for the STL Contributors Meetings. You can see some of the initial discussion in issue GH-921. We expect contributors who wish to attend the meeting to register beforehand (providing minimal information) and further details will be sent out closer to the date of the meeting.
The meeting notes here were subject to interpretation by the notetaker (they are not verbatim quotes, but are instead summaries of what was said) and are biased in terms of the notetaker's opinions in what was noteworthy and what could be omitted.
Italicized names indicate the speaker; Bolded text indicate actionable items
- Starting recording
-
Mahmoud: Rules:
- Mahmoud as moderator
- We will be going through the prepared agenda
- Please mute your mic if you’re not speaking
- If, during the meeting, you want to add something to the Agenda, please put it in the chat window
- We don’t expect to need to do any screen-sharing
- Quick introductions (20-30 seconds each)
- Mahmoud: organizer for the meeting, manager for STL, has been on many other teams at Microsoft as well
- Ahana: intern on the team, joined mid-May, has been working on ranges, spaceship
- Alex: from Ukraine, works with C++ often, started contributing to open source projects in our repo, favorite project is unique_ptr
- Casey: the “ranges guy”, WG21 stuff, STL maintainer
- Michael: has been doing C++ for 4 years now, worked for 3 years on compiler
- Charlie: bit things, U of M, research engineer on Machine Vision, worked on perception for self-driving cars
- Miya: intern before on this team (parallel algorithms), currently working on constexpr string, chrono
- STL: has been working on the STL since 2007, currently working on spaceship operator
- StrongNoodle: prefers to remain anonymous, worked at MS in 1995 and worked there for 16 years, then moved to a start up that was acquired by a very large company, now is writing a book
- Sumit: work at Microsoft (completely different team), started contributing because likes to learn new stuff!
- Ulzii: STL is first MSVC toolset chain to go open source, has mostly been on the compiler team, now leading the C++ language org, 20 years at Microsoft pretty much all on the C++ team
- Billy: Joined STL team in 2015ish, has been mostly working on concurrency/atomic stuff, soon will be moving to the vcpkg team but is still working on STL for another month(ish)
- Curtis: has mostly been setting up testing and CI in STL repo, comes from C++ in CUDA and prior to that was a completely C programmer, worked on vcpkg before moving to this team
- We’ve increased bandwidth (number of people on the team) but there are still lots of PRs piling up
- STL: made a graph showing total age of open PRs, this has been increasing. Yay, atomic things are being merged soon! We’re trying to clear out the few super old PRs and that will certainly help. Tests being open to the public is a huge help in this direction, and contributors are doing a good job writing tests. We’d like to see more contributors reviewing each others’ code! Then the maintainers can do a pickier pass toward the end. We’d like to hear anything that helps the maintainers be more productive.
- Michael: Thank you for being open to contributors! Responsiveness is awesome (doesn’t take months to have someone look at it initially), something that would help is knowing priorities of the team, so this would set expectations about when PRs would be looked at. Reviewing is scary, but if encouraging contributors to review others’ PRs was in the README, it would help!
- Casey: There is a low bar for contributing code, but there is a high bar for reviewing code! This is partly an artifact of being a newly-ish open-sourced project (not having any super long-term maintainers yet). Reviewing power right now is almost completely on STL because Billy has been away and Casey has been working on ranges because there is a deadline!
- Alex: Spaceship & ranges are priority for you, but atomics is priority for Alex. Whose priorities do we follow? Would you be open to shifting priorities? If not, maybe the maintainers will work on other things.
- Billy: Part of the wait on the atomics PRs was because Billy was gone and he is the atomics person. Other people will work on it in the future.
- StrongNoodle: Coding guidelines that are mentioned in the README (that will be here soon) would be super helpful (instead of doing work and having to fix after-the-fact with reviewing, many of the corrections could be implemented up front). Maybe even auto-style checkers. Maybe we also need to add performance tests?
- STL: We’re currently using clang-format for auto-styling (whitespaced). Contributor guidelines are high priority! Still working on it, but has been pulled away trying to hack away at the PR backlog. Initial responsiveness is important, communicating priorities/what we are looking at is important. In need of clarity of current priorities, tasks, etc.! Not really a matter of “atomics vs. Ranges", but also about who we have available. We should figure out how to say at a high-level what we’re working on (monthly iteration plans?). We never wanted to discourage anybody’s PRs, but we certainly need to prioritize some PRs over others (e.g., C++20 features).
- Charlie: Performance profiling...we have some rigorous full compiler perf tests, but for the STL the performance and benchmarking is pretty ad hoc at the moment. Billy prefers Google benchmark with different compilers/flags, Billy also likes vtune.
- Billy: (Regarding benchmarking) It’s been very one-off, we don’t have a formal benchmarking process. Plus it’s been difficult to transfer those one-offs over to the STL GitHub repo due to licensing stuff.
- Casey: Would it be helpful to put our priorities somewhere (public) so contributors would at least know why we’re not looking at some PRs?
- StrongNoodle: Maybe look into a discord channel or something where you can go there and ask a question. Allows more for a conversation with a maintainer, rather than comments specifically attached to a PR. Things like “vNext”?
- STL: Have examples of what a performance microbenchmark look like in the repo to make them more approachable to maintainers (number of iterations, what tools to use, etc.). Also need to look for regressions (performance and throughput) - compiler team has much more infrastructure to see this with each change...would be great to take this sort of structure for ourselves! BUT we are running tests on Azure right now, on noisy VMs which doesn’t allow for microbenchmarking as easily.
- Sumit: +1 to Casey’s comment – would like to see what’s coming, and more transparency in general. We should have examples of benchmarks!
-
Mahmoud: It’s the next ABI-breaking library. It’s the current library, but over the years we’ve accumulated many bugs that would break ABI. We’ve been keeping ABI-compat since 2016 to ensure users’ code stability. ABI-compat means that the surface area of the binaries stays constant.
- Eventually we will do this, need to get some approvals from stakeholders/managers first. Don’t have an exact date yet. Will probably also have C++23 features.
- NOTE: We will not start working on C++23 features until C++20 feature work is completed.
- STL: Staying ABI-compat is really, really good for users! STL is the only one who has worked through ABI-breaking time on the team. In preparation for vNext, need to port everything over from long-stagnant TFS but also need to decide what we actually want to do (regex, naming stuff, etc.). Once we start work, will need to communicate these priorities through these discussions.
- Sumit: What would the timeline look like? ABI change once every 5 years and then after that point it stays the same for the next 5 years?
- Mahmoud: (answering questions)
- STL: ABI-breaks frequently actually caused customers to not upgrade. After vNext, any project that needs to be upgraded would also need to upgrade all of its dependencies so....yeah....
- Sumit: Hey! Github has a discussions tab!
- Mahmoud: After C++20 is done, we’ll start looking at c++23, though that has been pushed back some due to COVID-19.
- STL: How to develop on both? A vNext branch? Seems expensive in terms of developer time...most efficient thing would be to only port C++23 features to the vNext branch (not also to the last ABI-compat branch). Seems like potentially a reasonable thing to communicate to customers. Then we can work on vNext and C++23 features in parallel, so then we wouldn’t need to backport C++23 features to an old branch (which can be a huge time sink).
- Mahmoud: Thank you! You’re making a huge difference with high-quality contributions. For future meetups, unsure of exactly when the next meetup will be. At the very least once every 6 months, but perhaps more frequently (especially if things start heating up in other GitHub threads).
- STL: Continue using the currently-pinned (not always to be pinned) GH issue for discussion about frequency of meetings, whether we should have more meetings focusing on specific topics, etc.