2019.03.01
As always, these minutes are also available on the compiler-team repository.
Zulip topic
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-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-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.