Skip to content

MSVC STL Contributors Meeting Notes

Jump to bottom
Stephan T. Lavavej edited this page Mar 28, 2024 · 10 revisions

MSVC STL Contributors Meeting Logistics

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.

Meeting Notes

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.

Underlined names indicate the speaker; Bolded text indicate actionable items; Italicized text indicate unspoken response/reaction (e.g., No one volunteering answers)

Meetup #3: 2021-09-15 9:00am-10:00am Pacific Time

Welcome & Introductions

  • Mahmoud Saleh: Welcome! Let’s do short intros 😊
  • Introductions of each attendee

Thanks from Mahmoud

  • Thank you all so much for all of your work!
  • I’ve been really happy with the repo.
  • We recently had an external survey go around to get an understanding of how happy our contributors were for all of C++ and Developer Division, and our repo has been ranked the best in all areas of the survey!
    • High satisfaction among contributors.
    • Positive feedback on interaction between contributors and maintainers, among many other areas.

Clarifying current priorities and focus areas for the repo

  • Mahmoud: Our focus is generally on Standards compliance!
    • C++20 defect reports (DRs) – We need to implement these as soon as possible and have them backported.
    • C++23 work – We’ve already had amazing progress here!
  • Mahmoud: vNext
    • The name for the ABI-breaking toolset and libraries
    • Unfortunately, we’re not able to focus on it right now, but we know that many really want it to happen.
      • We’ll need to wait for “the stars to align”; essentially we need several things to be in place in order to embark on vNext.
      • In particular, we need to make sure that the compiler front-end (FE) team is also ready for vNext.
      • Additionally, we currently have other higher-priority work that needs to be completed.
  • Alex G: So vNext is not a priority right now, but when it is finally time to start vNext work, there will be a lot of work to do since we’ve been waiting for so long.
    • So maybe it’s a good idea to really focus on other work right now and try to make progress there, because there won’t be time for it once we start in on vNext.
  • Curtis Bezault: Restating Alex’s comments.
    • Because we’re sort of waiting on a few things right now (we’re waiting for vNext, C++23 isn’t completely standardized yet, etc.), maybe we should try to clear out some of the backlog of old but useful-looking PRs that may be somewhat low priority but are still worthwhile and we would still like to check in.
  • Mahmoud: Yes, definitely. We actually have OSS meetings every week where we try to prioritize PRs and review work because we know there is a PR backlog
  • Stephan T. Lavavej (STL): We tend to work through PRs in sort of reverse chronological order. If newer PRs are close to being ready to check in and perhaps just need a small amount of work, we tend to try to get those over the finish line as often as we can.
    • However, this can lead to PRs languishing and sitting for months at a time.
    • Note that we do need to have some level of prioritization, especially for C++20 DRs and C++23 feature work.
    • We’re also always looking at our status chart for tracking the PR backlog – we are aware of the fact that some PRs have gotten stuck and haven’t made progress in a while.
    • When contributors review each others’ PRs, it is incredibly helpful in helping us make progress and requiring fewer iterations of maintainer reviews.
  • Mahmoud: Yes, we definitely have some work to do in this area.
    • I believe that a few PRs have maybe been sitting because we’re not sure what we want to do about them.
      • Perhaps we should mark those as “blocked” or something to indicate this?
    • STL, do you know of any PRs that should be marked like that?
  • STL: All PRs that are open are ones we would ideally like to merge.
    • There are a few PRs where we don’t want to merge it, but we need some time to back up this decision with reasoning and/or documentation.
    • At this point, there are just so many tasks on our plate that some lower-priority PRs have been starved for attention.
    • The one that is actually blocked is blocked by waiting for WG21 to finish fiddling with the chrono/format specification.
  • Charlie Barto: There are a few format-related PRs that are waiting in the backlog that have been reviewed and are ready to go, but there are some things that haven’t made it through some of the committees yet and haven’t been voted into the Standard, so they’re just sitting until they’ve been Standardized.
    • Because anything we check into main will flow into new versions of VS, these PRs just have to wait until things are officially Standardized.
    • We do understand that authors of those PRs may be frustrated seeing no progress on them for so long.
  • Michael Schellenberger Costa: Perhaps using P0, P1, … labels could help communicate these priorities to contributors and organize work?
    • Right now, you only know that your PR is “in the queue” but perhaps using these labels would help authors better understand when their work might be addressed.
  • Mahmoud: That idea sounds promising.
  • Curtis: I’m skeptical regarding the usefulness of adding yet more labels to our system. I’d prefer to simply be stricter in our prioritization: If something is high-priority, then work on it.
    • Otherwise, we should just sign up for what we think we can actually get done.
    • Maybe maintainers just need to work on keeping track of what needs to get done before others.
  • Mahmoud: Maybe we can find a compromise or brainstorm more ideas…
    • It sounds like this warrants more discussion, and we won’t be able to make an absolute decision this very second.

ABI-Stability timeline for C++20 in VS 2019 16.11.x and VS 2022 17.x

  • Mahmoud: We are currently maintaining GH-1814 regarding our ABI stability timeline.
    • To summarize:
      • For things that are still “undergoing work”, they remain under the /std:c++latest switch until those features have been stabilized.
      • Once that happens, we will move them under /std:c++20
      • Currently this applies to chronat (chrono/format intersection), format, and -- these features are still under /std:c++latest.
    • Charlie and Casey have been very vocal among the WG21 committees regarding this unfortunate situation and have made it known that we can’t continue to accept retroactively-breaking changes this way.
  • Charlie: We implemented these new features quickly, but we were also able to rely on already-existing implementations as we did our work.
    • We were fast and as a result, the committees were caught off guard – they thought they had more time to fiddle with things.
  • Casey Carter: If people don’t have an implementation to look at early on, they don’t realize that there are things to fix until after that implementation has been finished.
    • Either you’re an early implementer or a late implementer.
    • If you’re the former, you get punished by being broken by changing specifications.
  • Charlie: Unfortunately, all of the implementers can’t just wait for an entire year – someone has to be the guinea pig.
    • The current status quo: a feature is proposed, people wait for it to be standardized before using it, then people use it and have changes they want to make.
  • Guy Davidson: In LEWG at least, these “time machine” proposals are at minimum viewed in contempt by many (including myself).
    • People do want to fix things, but there is a process to follow.
    • I am very grateful that you’ve been so prompt in releasing features, but I agree with Casey, you’re now getting punished.
  • Curtis: So Guy dislikes time machine proposals...but is also suggesting that we shouldn't feel the need to go so fast?
  • Guy: Yes it’s a bit of a contradiction…
    • But if you weren’t immediately stuffing everything into /std:c++latest, it wouldn’t be the end of the world and you probably wouldn’t be in this situation.
  • STL: The issue is not that we stuffed things under /std:c++latest.
    • The issue is more that we were about to add the /std:c++20 switch and then realized that we were going to have these breaking changes coming from WG21.
    • If we’d had more foresight, we would have just held things under /std:c++latest and there would have been a “feature-complete” stage and an “ABI-stable” stage.
    • We can continue to implement features as they come in (under /std:c++latest) to keep up and provide that early implementation, since ABI is not locked under /std:c++latest.
    • For C++23, I imagine we’ll hold off on adding the /std:c++23 switch for a while to make sure things have actually settled before locking ABI.
    • Maybe C++23 will not have backports and we’ll be more confident in adding /std:c++26, but since we’ve been burned once (with C++20), I think we should be cautious.
  • Charlie: Yeah, if you really need ABI stability, it’s probably not the worst idea to wait a release or two just to be safe.
  • Guy: Is there a difference between implementing and shipping to you all?
  • STL: To us, there isn’t really a difference.
    • We should be fairly stable; we’ve been “ready to ship” for like a decade; as far as we’re concerned, once it’s checked into the repo, it’s “shipped.”
    • VS releases are essentially a “snapshot” of what we have at that particular moment.
    • The distinction I’m making here is between putting things under /std:c++latest vs. /std:c++xx.
  • Guy: That makes sense, thank you.
  • Guy: I really do appreciate the long-standing ABI stability that you’ve been able to provide.
  • Mahmoud: Once we have received those finalized changes from WG21, we’ll move those features under /std:c++20.

Where are we with vNext plans

  • Mahmoud: We need to make sure that ABI remains stable for as long as we can.
    • Once we have enough agreement from parties and see enough value in proceeding with vNext, we’ll be able to go ahead and start work on vNext features.
      • We may even be able to start a little early.
      • However, currently it’s not a priority.

Process for providing reference and early implementations for C++ features in the repo

  • Mahmoud: This seems like it would be really helpful!
    • This is also related to the ABI-stability issue actually – if people writing proposals were able to actually implement them before they’re voted in, there would probably be fewer changes made after the fact.
    • I believe we can’t merge early implementations of non-Standard features into the repo, but what does everyone else think?
  • STL: It makes sense for someone to fork the repo and start their own implementation and maintain it.
    • Then, once it’s accepted by the committee, they can create a PR into our main.
    • We’ve been burned before with things like this, which is why we are really hesitant to go beyond the Standard unless the Standard has contained unimplementable or obviously contradictory wording.
      • Once we ship something we expect to be voted in, people depend on it whether it gets voted in or is rejected.
  • Guy: This is of particular interest to me because of the linear algebra proposal.
    • If I can develop in a fork and build and everything, I’d like to have it in shape for you to accept pretty easily once it is voted into the Standard.
  • Mahmoud: As things are defined now in the STL, it would allow you to test and verify your proposal in your fork.
  • Guy: I haven’t started it yet, but I expect to be able to around the end of the year.
    • I may need a little support from you all for style, etc.
  • Mahmoud: The “Getting Started” section of the README will be particularly helpful to you!
  • Charlie: If goal is for the linear algebra work to actually land in the msvc repo eventually, we could probably give it some maintainer time. Sometimes we’re able to review stuff that may not yet be ready to merge if the target is for it to be eventually checked in.

How to improve process/resources for first-timer contribution experience

  • Miya Natsuhara: Main idea that I think could be helpful without a huge amount of time investment is the idea of “meta-documentation.”
    • It can be very overwhelming for newcomers to encounter the repo, and there is a lot of knowledge that just lives in the brains of maintainers and contributors.
    • Granted, it can be hard to invest time in documentation because by the time it’s polished and ready to go, the story may have changed and the documentation becomes outdated.
    • However, the idea here is not to document actual info necessarily, but instead how new contributors can find that information (e.g., directing to the Discord, other maintainer-endorsed resources like cppreference, tips on how to use https://wg21.link, etc.)
  • Mahmoud: Do others have thoughts?
  • Alex: I have another idea: currently, there is no documentation on how to break ABI. But, these things can be good to know for contributors, and right now it seems like maintainers don’t have enough time to document it.
    • Instead, maybe we should make a place for this documentation, and then contributors can help document some of this knowledge.
    • Perhaps we can expand the wiki? A lot of the documentation we have is older and outdated.
  • Mahmoud: I love this idea!
  • Alex: Right now, have a PR related to documentation. If that’s reviewed and approved, then I can continue to work on more documentation.
    • GH-2141
  • STL: We saw that PR!
    • It’s currently assigned to me, I just need to review the changes and tweak grammar/verify accuracy, etc.
  • STL: For things like ABI stability, that is definitely something that I plan to cover in the contribution guidelines (when I get to them).
    • To some extent, a lot of this knowledge just lives in the heads of maintainers. We’re not keeping it in some secret internal documentation or anything.
    • We’re sort of at the bleeding edge of this work in the world, so we do need to write down some of this knowledge.
    • Since I’ve seen the most of the ABI stability story, it probably makes sense for me to be the one to do this.
  • STL: In terms of the import library, we really appreciate the work you’ve done to write that down – your experience there in adding the atomic wait DLL is really valuable and you’re maybe one of the most important authors of that.
  • STL: The question is whether that’s best at home in the repo or in the wiki.
    • The wiki itself is a repo, but I’m not sure if we can set up PRs for it?
    • Ideally, we could make the wiki world-editable by contributors (it’s currently restricted to edits by maintainers I believe).
    • We do have the capability to add collaborators – we would need to look through the MS guidance on how/when we’re allowed to do that.
  • Miya: It’s also worth noting that cpp-docs (docs.microsoft.com) is also open-source, so contributors are also welcome to submit changes there if it makes sense for it to be in the public, user-facing documentation.
  • Mahmoud: Yes, I just contributed to that repo!
  • Alex: For some things, it might make more sense to keep the documentation in comments in the associated code rather than in the wiki.
  • Miya: Agreed – if there is user-facing information, it may make sense for it to go on docs.microsoft.com.
    • However, if there is documentation that is purely for the use of actually developing code, that probably belongs in documenting comments or perhaps in the STL wiki.

Wrap-Up

  • Mahmoud: Unfortunately we’ve run out of time, but there is one more thing I wanted to bring up: we’ve been posting code review videos on YouTube (wiki page).
    • We heard that there may be desire to do contributor code reviews?
      • No objections, encouraging smiles
    • Maybe we can continue the conversation around how to do contributor code reviews.
    • Please reach out via discord and let us know if you are interested!
  • Mahmoud: Awesome, thank you! We didn’t get to everything on the agenda, but we can continue conversations online 😊

Meetup #2: 2020-12-09 9:00am-10:00am Pacific Time

Welcome & Introductions

  • Mahmoud Saleh: Welcome everybody!
    • We had our first meeting like this in April this year, we plan to have these contributors meetups quarterly or maybe twice per year.
    • The meetup last time was found to be very valuable – we made many changes as a result of the first contributors meetup. (e.g., we set up a discord, we’ve found new ways to streamline the CR process, etc.).
    • We want to continue to improve our workflow and make other changes as a result of these meetings.
    • Thank you for making this a productive, successful open-source environment!
  • Introductions of each attendee
  • Amy Wishnousky: Spends time on the VCRuntime and VCStartup parts of the library, both of which will be open sourced as well in the near(ish) future!
    • Mahmoud: VCRuntime, UCRT have been desirable to open source for a while, but it’s been difficult to do so up until now.
    • Mahmoud: The UCRT provides functionality for printf, etc. ; VCRuntime provides the glue for the compiler and Libs code
  • Mahmoud: Starting transcription now 😊

Repo Status

  • Mahmoud: Throughout the last year and even before the first contributor’s meetup, after open-sourcing the STL, we learned that we need to do a lot of organization to help everybody be productive and increase communication [between maintainers and contributors].
  • Mahmoud: A few things to highlight since the last meeting:
    • GitHub discussions tab
    • STL’s status chart showing the progress being made in the repo
      • https://microsoft.github.io/STL
      • Actually, it’s 3 status charts!
      • In particular, highlighting the L(E)WG issues line and line for C++20 features (ever since open-sourcing the repo, you can see the C++20 features line sloping downward nicely).
      • STL: The chart shows the total age of PRs with the black line; in particular we have a few older PRs (chrono, Optimize Random) that are bringing the combined age up significantly.
        • The red line tracks the combined amount of time that PRs have gone without a “changes requested” from a maintainer, so that is always equal to or below the black line.
      • STL: Monthly merged PRs chart logs how many PRs are merged every month. It’s clearly showing vacation time, ramping up before CppCon, delays during CppCon, holidays, etc.;
        • The lines aren’t weighted for lines of code changed or anything in each PR, but just considering all PRs as equal.
        • A good way to get a rough view of the level of activity in the repo at any time.
      • STL: If you have any ideas for what to add to the status chart, let us know – it’s all maintained by us, so we have complete control over what info is included.
  • Mahmoud: We have also started using GitHub projects to track the progress on some of these large features that have a lot of pieces involved; trying to improve organization, communication, and workflow.
    • E.g., P1614R2 Spaceship, chrono, formatting
    • Any ideas, references, etc. for what you’d like to change so we can make things better (including changes to projects, adding new projects, etc.) – please let us know!

C++20 Features Status

  • Mahmoud: C++20 features project
    • “Available” means that no one has touched except for creating the issues and linking papers, but otherwise are open for someone to claim and start working on!
    • We are very close to being done!
  • Mahmoud: What is the best way to move forward to finishing the remaining C++20 features?
    • Anything we should change? Any ways in which we can motivate people to move forward and help us finish implementing the few remaining pieces?
    • Michael Schellenberger Costa (miscco): I’ve been trying to go through the list and work on what I feel I can, but otherwise I think it’s going fast and we’re making progress!
      • There were definitely a few things where I was like “variant? NOPE”
    • Mahmoud: Has there been anyone unaware of this project? No answers Good.
  • Mahmoud: STL has been working on modules and header units, Casey has been working on ranges…
  • Casey Carter: We’re almost done with ranges! We have lots of things in PRs right now (join_view from Michael, allocating algorithms, iota_view, etc.) – hopefully we’ll get everything done in time for 16.9, we are getting really close! I don’t think I could have done as much as we have without Michael’s help – it would have taken me another year!
  • Mahmoud: Ranges are the biggest feature C++20, hopefully can declare victory soon! We will be one of the first libraries shipping a full implementation of ranges.
  • Mahmoud: Miya has been working on the chrono feature.
  • Miya: We are well on our way with chrono, another large C++20 feature.
    • We’ve had a very large PR contributed by SuperWig (GH-323) adding pretty much all of the calendar types plus more, and I think it’s over 2000 lines of code being added. That’s currently on STL’s long list of PRs to review, so it is on its way to being checked in!
    • We’ve also had MattStephanson’s duration IO PR that has already been checked in since it had no dependencies on GH-323.
    • Most of what is left is chrono formatting things (we have some dependencies on std::format for that, so I’ve been talking with Charlie to make sure we have an idea of how everything is going to fit together there) and time zone things. We have some tentative plans to look into some Windows system headers to get the actual time zone information. We need to do a bit more investigation there, but we are on our way.
    • Mahmoud: chrono should be wrapped up sometime early next year. Our plan is to get C++20 done in 16.10, our goal to get it done in the first few months of 2021.
  • Mahmoud: We will be the first repo to complete C++20!
  • Mahmoud: Charlie is working on std::format
  • Charlie Barto: We are “adopting” libfmt’s implementation – a lot of the structure of the code is the same, but we’re not copy&paste-ing or anything like that. I’m going line-by-line and simplifying it, making it work with our repo, etc. libfmt is large (~10,000 lines), so it’s taking a while but the hope is to get some form of output working in the 16.9 time frame.
    • std::fmt, like spaceship, is being developed in its own branch; if anyone has extensive knowledge of libfmt, we would really appreciate that knowledge as PRs come up for review!

C++20 Feature-Complete Plan

  • Mahmoud: Lots more to do, but lots of progress been made!
  • Mahmoud: Are there any obstacles to your progress? How can we improve the experience of contributing to the repo?
    • Anyone here contributing to LLVM as well?
      • Michael: I tried, but it wasn’t the best experience – after submitting changes, there was a lot of waiting.
        • I believe they’re hiring another maintainer so maybe things will improve, but the bottleneck right now is just waiting for reviews.
      • Mahmoud: Yes, I’ve been hearing the same sorts of reports. Their success is our success; C++ is a community, we don’t view them as competitors…we want C++ developers to be able to have portable code and better code that will work everywhere. We don’t contribute much to LLVM nowadays (mainly for the same reasons you mention – it often takes a while to get changes reviewed). For example, STL has tried to contribute his charconv implementation in the past. However, I think in the future we will also be increasing our contribution and participation in LLVM and other repos (not a priority right now, but perhaps in the future).
      • Michael: Organization/authentication is also a challenge when working with LLVM; you need to have a Phabricator account, etc. – it is a bit arcane. Modern workflows (like in the GitHub repo) here have been much better.
  • Curtis: Is there anything in the testing process, etc. that is painful for anyone, that I could maybe focus on addressing in the near future?
    • No one volunteering complaints.
    • STL: We’ve made a lot of progress recently in speeding up tests hugely, bringing more testing for arm64 online, quota increases for VMs.
      • Now it takes ~8-10 minutes for PR build, whereas before it took closer to 1h or even several hours if there were many PR runs queued.
      • We’re still looking for ways to make it even faster, but I think if anything we should try to improve clarity of test failures (currently it can be difficult to debug and understand why something is failing). Between Azure pipelines and GitHub, we want to try to make it as easy as possible to understand why something is failing
      • We already have one TODO to actually point out in the code format validator WHERE non-ASCII characters are, not just that they exist.
      • Please do let us know if there are other pain points we should address! Fresh eyes can sometimes help point out things that are confusing or unclear.
  • Mahmoud: Goal is to get everything C++20 done by Feb/March-ish!
    • Yes, we’re all going into vacation mode along with many others so last 2 weeks of December and first week or so of January will probably be slow (apologies).

vNext Plan

  • Mahmoud: vNext is the name that we’ve given to the next release of Visual Studio, next version of compiler, libraries, etc.
  • Mahmoud: There is a vNext planning page on the GitHub wiki from STL.
  • STL: We had worked on a vNext branch back in our Team Foundation version control days back in 2017, but a TON has changed since then.
    • Once we finish C++20, the plan is to focus on vNext
    • Working on both C++20 features and a vNext branch simultaneously doesn’t seem advisable; a clean switchover seems best for everyone.
    • Once we begin a vNext branch, we’ll try to port over the changes that we had already implemented (e.g., Billy multithreading overhaul, iterator debugging overhaul, removing clr:pure)
    • On the wiki page, we are trying to collect vNext ideas – that can be done in parallel with C++20 work, we just can’t actually make the changes right now!
    • If you think of other things that should be included in vNext, file an issue and we can make sure it has the vNext label – that is how we accumulating a list, then we will then need to prioritize.
    • We are still unsure of how long we will have to work on vNext before needing to move on to work on other things, so we’ll need to work out a prioritized list as we may not be able to fit in everything we would like.
    • In particular, we know that we definitely want to overhaul our regex implementation, so if anyone has particular interest there, let us know! It’s a bit of an open question right now:
      • Should we write something new from scratch? Take inspiration from boost’s implementation? Try to take libc++’s implementation?
    • Overall idea for vNext: overhaul what we can/want to do that we can’t normally because of bincompat; we will have larger (though not infinite) resources for destabilizing (bin- and source-compat-affecting) issues.
    • We also want to remove extensions (e.g., <hash_map>, <hash_set>).
    • Note: we also don’t really know what the compiler will be working on because they’ll be working within the same vNext timeframe; let us know if you want us to bring up compiler issues or you can ping them directly on Discord, GitHub, etc. 😊
      • We do know that they’re going to do things like refine the empty base class optimization, and other potential layout things.
    • Michael: What about the C++ standard version targeted? Who do we have to shout 20 at?
      • STL: That would be potentially very source-breaking…it could/would be very discouraging for people to also have to jump standards version along with vNext things (as much as we would like to be able to say default is C++17 or something).
  • Mahmoud: We are in the middle of our vNext planning, but we won’t be doing any C++23 or vNext work until we finish C++20 ; please, if you have any ideas or things you’d like to see in vNext, please let us know.
  • STL: When we switch over into working on vNext, I think we will be still able to merge C++23 PRs (lower priority than vNext because vNext is time-boxed).
    • Logistically, we just can’t accept any C++23 PRs right now because we don’t have a C++23 switch – once we finish C++20, that will have its own switch and C++latest will become c++23 – the timeline should work out where this will also be the start of work on vNext

Questions / Issues

  • Hamid Arzaghi: Suggestion (not about vNext): I prefer to have some suggestion or guidance from maintainers when fixing bugs/issues; it’s easier for me to contribute on issues that have some guidance/suggestion/ideas on the issues from maintainers on where to start.
    • STL: Would have some issues tagged “help wanted” help indicate what we think are reasonable fixes or are approachable to work on?
    • Mahmoud: We also have the high priority tag, those can be good clues for things to start with.
  • Matt Stephanson: Regarding chrono – parsing, clocks…I have some work on these which are dependent on #323…just letting you know.
    • STL: Maybe you could comment on the issue or track it in project somehow to avoid having other contributors duplicate your work; unfortunately, GitHub doesn’t have a good way to stack PRs on top of each other…maybe it would have been a better idea to have a feature branch for chrono in retrospect. That way we could have things checked in more frequently with just lightweight review and then when the entire feature branch is merged in, that’s when we have really rigorous review.
      • We typically only make feature branches for really large features that require multiple PRs to be completed (though this didn’t apply for ranges – there we really did want everything to be checked into main).
    • Charlie: having the feature branch allows us to have a lower bar for reviews before things get merged into the feature branch; can be nice to unblock you when you’re working on one of these multi-part features.
  • Mahmoud: That’s all we have time for – thanks to everyone who participated in the meetup today, it has been a great discussion! We’ll be posting some meeting notes, and we will have more of these meetings in the future, maybe every 1-2 quarters.

Meetup #1: 2020-07-22 9:00am-10:00am Pacific Time

Introductions:

  • 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: Works 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

Large Backlog of PRs in the GitHub Repo

  • 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!

vNext

  • 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).

Closing

  • 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.
Clone this wiki locally