2019.03.01
Before the meeting started, @nikomatsakis proposed an agenda and linked to a document to collect agenda ideas for future meetings.
Also, @mw asked about discussing the policy for out-of-tree compiler crates (expanding on discussions from the All Hands' organizational meeting), a draft for which was already in-progress by @davidtwco.
The meeting commenced with a call for involvement in the RLS 2.0 working group led by
@matklad as sharing expertise between the RLS 2.0 effort and rustc would be helpful.
There is documentation (videos and guides), issues with E-mentor and other resources available
for those interested. @davidtwco, @pnkfelix and @Xanewok
mentioned that they would endeavour to find some time to dig into RLS 2.0.
Next, @nikomatsakis announced an ongoing effort by @spastorino to collate an expert map about who has expertise in which areas of the compiler, with the intent of making it easier to find the right people to ask questions and assign issues/PRs to, and invited everyone to help flesh it out and add themselves. @nikomatsakis also suggested that this would be good in documenting the overall structure of the compiler in some ways.
Following this, the main topic for the steering meeting, the out-of-tree crates policy was discussed (for things like polonius, chalk and the upcoming diagnostics refactoring). The current draft of the policy was linked and @davidtwco emphasised that it was very much a draft and there are lots of unresolved questions.
@nikomatsakis highlighted a desire for having a uniform experience between out-of-tree crates and normal in-tree development - particularly surrounding who can land PRs, highfive reviewer assignment, and ensuring anyone in the team can publish new crate versions.
@davidtwco noted that discussions surrounding tooling that could make out-of-tree crates easy to work with was left out of the policy draft as that isn’t part of the policy.
Both @nikomatsakis and @mw wanted there to be a simple guide to follow for creating out-of-tree crates - this should include links to examples and things to copy-and-paste.
@pnkfelix raised concerns about current policy wording suggesting that only general-purpose functionality should be factored out and suggested clarifications about the minimum bar for expected re-use might be beneficial. @nikomatsakis mused that making libraries too general purpose could carry a higher maintainance/breaking-change burden. @mw suggested that this would need to be decided on a case-by-case basis. @nikomatsakis clarified that we should absolutely be following semver in these crates.
@nikomatsakis then raised the question of review policy in out-of-tree crates - should major PRs require multiple reviewers? can crates have reviewers that are not reviewers of rustc? Going to on say that the idea of these crates having their own communities is appealing and that one option might be that if a contributor was involved in crate sufficiently to review it, then perhaps they should get rustc r+ too or that out-of-tree crates might offer a way to do more fine-grained notions of r+. @pnkfelix suggested that long-term we might want in-tree tests of these crates to guarantee that they maintain compatibility.
@mw then proposed walking through an example - the self-profile working group will likely create a mildly sophisticated on-disk string table that will be shared between rustc and external tooling created by the working group and that this would be an ideal candidate for an out-of-tree crate.
This raised the many questions. Do compiler team members have the rights to create repositories in the rust-lang organization? Is it best to start in the rust-lang organization or prototype in a user-hosted repository? What do we name these crates? Is there guidance on adding crates.io dependencies to rustc?
@davidtwco suggested that we would need to collate a list of things that would need to be added to a repository (licenses, code of conduct, etc.) and things that would need set up (bors, highfive, etc).
@wesleywiser mentioned that while anyone on the compiler team should be able to r+, only those actively involved should be on the highfive rotation. @nikomatsakis noted that it would be great for active working group members to have the opportunity to gain r+.
@mw asked if we would set up community infrastructure (such as Zulip instances or streams) for the out-of-tree crates, but @nikomatsakis thought it best that this be tied to the community infrastructure already in-place for the working group.
Then, @nikomatsakis re-raised the question of whether these out-of-tree crates are best kept in the rust-lang organization. @mw suggested that this is best as it simplifies bors and highfive integration and would use existing team permissions. @pnkfelix asked how challenging migration from a personal repository to the rust-lang organization is. On this point, @nikomatsakis said that transferring is easy but messy - transferring can leave a redirect behind which will conflict with the default name of a fork, which requires an email to GitHub to resolve.
@davidtwco interjected that it should be made clear what team and working group is responsible for any repository we create in the rust-lang organization. @nikomatsakis suggested a template for the README of out-of-tree crates would be valuable and should point to the responsible working group.
Changing gears, @mw asked if there were any example workflows for handling changes in external crates to which @nikomatsakis suggested that a rustc-dev-guide chapter on that and how to make local copies for debugging would be necessary. @davidtwco asked what information should be kept in the policy document and what information should be kept in the rustc-dev-guide. There was some consensus that setting up a new out-of-tree crate is policy and working with one is for the guide.
@mw then raised the question of where consent of compiler team members should be gathered
before creating new out-of-tree crates. @pnkfelix suggested it could be a triage meeting
item and @nikomatsakis suggested using @rfcbot and that the general presumption
would be that if a compiler team member wanted to create a out-of-tree crate then it would probably
be a good idea. @mw mused that something asynchronous would be preferred and that agreement
within the working group itself should come first. @nikomatsakis suggested that
the goals of approval should be discussed, such as helping to pick a suitable name.
@mw suggested that a list of these crates would be valuable and there was agreement that it should not be in rust-lang/rust to avoid the bors queue. There was some discussion about searching for issues across repositories in an organization.
@davidtwco then agreed to write these minutes and his hands are starting to get tired at this point.