Merge pull request #26 from davidtwco/steering-meeting-02-03-19-notes

Add steering meeting minutes for 02/03/19

Author: nikomatsakis

minutes/steering-meeting/2019.03.01.md

@@ -0,0 +1,125 @@
+# 2019.03.01
+
+[Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E01.20.2358850/near/159650062)
+
+Before the meeting started, [@nikomatsakis][nikomatsakis] proposed an agenda and linked to a
+[document to collect agenda ideas](https://hackmd.io/wsHwsi9zR3iq0ZF2SgEq9Q) for future meetings.
+
+Also, [@mw][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][draft_policy] was
+already in-progress by [@davidtwco][davidtwco].
+
+The meeting commenced with a call for involvement in the [RLS 2.0 working group][rls2] led by
+[@matklad][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][davidtwco], [@pnkfelix][pnkfelix] and [@Xanewok][Xanewok]
+mentioned that they would endeavour to find some time to dig into RLS 2.0.
+
+Next, [@nikomatsakis][nikomatsakis] announced an ongoing effort by [@spastorino][spastorino] to
+collate an [expert map](https://hackmd.io/Izvor8KZRiqUgcUyd2CYTw) 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][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][polonius], [chalk][chalk] and the upcoming diagnostics
+refactoring). The [current draft of the policy][draft_policy] was linked and [@davidtwco][davidtwco]
+emphasised that it was very much a draft and there are lots of unresolved questions.
+
+[@nikomatsakis][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][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][nikomatsakis] and [@mw][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][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][nikomatsakis] mused that making
+libraries too general purpose could carry a higher maintainance/breaking-change burden. [@mw][mw]
+suggested that this would need to be decided on a case-by-case basis. [@nikomatsakis][nikomatsakis]
+clarified that we should absolutely be following semver in these crates.
+
+[@nikomatsakis][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][pnkfelix] suggested that long-term we might want in-tree
+tests of these crates to guarantee that they maintain compatibility.
+
+[@mw][mw] then proposed walking through an example - the [self-profile working group][self_profile]
+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][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][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][nikomatsakis]
+noted that it would be great for active working group members to have the opportunity to gain r+.
+
+[@mw][mw] asked if we would set up community infrastructure (such as Zulip instances or streams) for
+the out-of-tree crates, but [@nikomatsakis][nikomatsakis] thought it best that this be tied to
+the community infrastructure already in-place for the working group.
+
+Then, [@nikomatsakis][nikomatsakis] re-raised the question of whether these out-of-tree crates are
+best kept in the rust-lang organization. [@mw][mw] suggested that this is best as it simplifies
+bors and highfive integration and would use existing team permissions. [@pnkfelix][pnkfelix] asked
+how challenging migration from a personal repository to the rust-lang organization is. On this
+point, [@nikomatsakis][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][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][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][mw] asked if there were any example workflows for handling changes in external
+crates to which [@nikomatsakis][nikomatsakis] suggested that a rustc-guide chapter on that and
+how to make local copies for debugging would be necessary. [@davidtwco][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][mw] then raised the question of where consent of compiler team members should be gathered
+before creating new out-of-tree crates. [@pnkfelix][pnkfelix] suggested it could be a triage meeting
+item and [@nikomatsakis][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][mw] mused that something asynchronous would be preferred and that agreement
+within the working group itself should come first. [@nikomatsakis][nikomatsakis] suggested that
+the goals of approval should be discussed, such as helping to pick a suitable name.
+
+[@mw][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][davidtwco] then agreed to write these minutes and his hands are starting to get tired
+at this point.
+
+[rls2]: https://github.com/rust-lang/compiler-team/tree/master/working-groups/rls-2.0
+[self_profile]: https://github.com/rust-lang/compiler-team/tree/master/working-groups/self-profile
+[draft_policy]: https://github.com/rust-lang/compiler-team/pull/19
+[chalk]: https://github.com/rust-lang-nursery/chalk/
+[polonius]: https://github.com/rust-lang-nursery/polonius
+
+[davidtwco]: https://github.com/davidtwco
+[nikomatsakis]: https://github.com/nikomatsakis
+[pnkfelix]: https://github.com/pnkfelix
+[Xanewok]: https://github.com/Xanewok
+[matklad]: https://github.com/matklad
+[mw]: https://github.com/michaelwoerister
+[spastorino]: https://github.com/spastorino
+[wesleywiser]: https://github.com/wesleywiser