T-spec meeting 2024-05-16

--- title: T-spec meeting 2024-05-16 tags: ["T-spec", "meeting", "minutes"] date: 2024-05-16 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-05-16 url: https://hackmd.io/zNVE62x9SRefONe4vJXh3g --- Attendees: Joel Marcey, Mara Bos, Pietro, Eric Huss, Lucas Wirth, TC, Pierre-Emmanuel Patry Potential Agenda: * [Reference as 0.1](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Adopt.20the.20Rust.20Reference.20as.20version.200.2E1) * [Semantic Issue Labels](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Issue.20labels) ([Issue #52](https://github.com/rust-lang/spec/issues/52)) * Core Library Fit * [Where should "lowering" from Rust to Minirust go.](https://github.com/rust-lang/spec/issues/57) ## Adopting Semantic Issue Labels [GitHub Issue #52](https://github.com/rust-lang/spec/issues/52) Joel: Has added all new labels to the repo and modified existing labels to match proposed as well. Connor: Will PR to relevant places to add triagebot to the rust-lang/spec repository. ## Rust Reference = Spec 0.1 [Context](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Adopt.20the.20Rust.20Reference.20as.20version.200.2E1) Joel: I had proposed adopting the Reference, for the reasons explained in the comment in the thread. This has attracted some support, but it's also generated much discussion, especially today. Connor: If what we choose doesn't have the same style as the specification, we'll have to spend time rewriting it to put it into the structure that we want. So I hesitate that we'll spend as much time rewriting it stylistically, in some chapters, as much as we would rewriting things from scratch. Joel: I have a strong opinion here that updating the style of a document is a hurdle that's much easier to overcome that writing from scratch. Reformatting is mechanical and someone can just churn through it. That's a lot easier than starting from a blank document. Pietro: If we wanted to adopt something as the base, why wouldn't it be the FLS. Not speaking from the Ferrous hat. But the one rule per paragraph. Structure the specification to have separate for dynamic layout, etc. it will be a lot of work for either document, but the Reference doesn't have close to the structure we want. A second concern, if the Reference is 0.1 (or even FLS) what does change in practice? Joel: having some content may make it easier for people to come in and help in writing the specification. TC: Some points: - First, I wanted to express support for Joel here. Joel has a tough job as the owner of this difficult work. We need to give him latitude for how to make forward progress here. - We should acknowledge that not adopting the FLS is of course unfortunate, in a sense. Clearly a lot of work has gone into that. But much work has also gone into the Reference. We need to adopt something. - Adopting the Reference is more straightforward for the project, both techincally and because of how it's already integrated into processes of the project. E.g., people writing RFCs and stabilization reports already update the Reference, and people are familiar with the document and how to do those updates. - There's been a lot of resistance to adopting the FLS, both publically and privately, and that's been blocking us from adopting anything. It just doesn't seem that we'd be able to build a consensus in favor of adopting the FLS, but that shouldn't block us from adopting anything at all. - There's been substantial review of the Reference by the teams, and those reviews are very expensive. We should build on that work. Is the Reference perfect? No. But much has been reviewed, and there's a lot of value in building on that. - Regarding the concerns about how the Reference may not have the style or formatting we want, this is straightforward to address quickly. If nothing else, the Foundation could easily contract a technical writer to mechanically churn through these changes in a few weeks for a relatively small amount of money (which is something the Foundation has available). - We have to consider parallelism. This is going to be a collaborative process, and collaborative processes work better starting from a larger kernel. Even if, for sake of argument, we were to say that starting from the Reference is more total work, being able to better parallelize that work has a lot of value. - We don't want to end up with two documents. We already have to maintain the Reference within the project, and contributors are expected to update it when e.g. writing RFCs and stabilization reports. Having to maintain two documents, probably for years, is a major cost that's worth avoiding. - The main problem of the Reference is that it's undermaintained. If all of the good energy that's been going into our specification discussions could be turned toward improving the Reference, that would go a long way toward resolving the main challenges the Reference has. - Again, it's important to support Joel here and give him the needed lattitude in approaching this challenging task. Mara: Joel is having to do a lot of work and that should give the freedom for Joel to choose how to do some of that work. Ferrocene spec (FLS) is a lot closer stylistically but could have more mistakes than the Reference. Joel: Willing to fight to adopt the FLS within the Project if t-spec and interested folks agrees that we should go that route. Pietro: Didn't think Joel was going to be making big decisions. Only small tactical decisions like what labels we use. Believes adopting the FLS is way less work Mara: Believes there is more errors in the FLS beyond syntactical errors. Connor: Do not make decisions based on not full discussion among the t-spec. Connor: Not necessarily true that the Reference is better content-wise, it has a lot that the spec shouldn't necessarily have * https://doc.rust-lang.org/stable/reference/linkage.html Pietro: Joel's power isn't just mundane work. Apologizes if it came across that way. Knows the FLS is far from perfect, but we should still have the discussion. Mara: Most of us don't have time to work on this, and whatever works best for Joel is what we should choose.Take the useful parts of the FLS and the Reference and put it one place. Are we going to put PRs to an empty repository or into a repository with content? TC: With respect to the resources that Ferrous Systems could perhaps provide, the question seems to come down to whom the owner of the work would be, in the sense of Niko's project goals. If Ferrous Systems could be the owner of this work, and could commit the resources needed to be that owner, then adopting the FLS could make more sense. In that world, the project's involvement is perhaps more limited to setting standards for the outcome and review. TC: However, if the *Rust project* is going to be the owner of this work, then that's where the Reference starts to make a lot more sense, e.g. in terms of existing familiarity of contributors and integration into project processes. Pietro: We want this effort to succeed. If can convince Ferrous to put resources, then we would be willing to do that. But only if we adopt from the FLS. Cannot convince Ferrous to spend money on work that has already been done but is not being used. Mara: FLS and Reference has different goals. FLS has a specific purpose for Ferrous. Was written quickly for their purposes. Reference was better for RFCs and work for the Project. Joel: Would people support me if I had picked the FLS: Mara: I'd support you, but I'd have a lot more questions and reservations. Connor: There are process questions that need to be solved for how to adopt the Reference, so I don't see this as being an advantage for adopting the Reference. Joel: The FLS clearly would have process questions also. TC: As a strawman -- and there are many other ways we could do it -- we could simply turn our energies toward supporting the existing processes of the Reference and add a link on the Rust website (and to the Reference) labeling it the "draft" (or "alpha" or whatnot) version of the Rust Specification. Not saying we necessarily need to do it that way, but we *could*, and that would immediately solve the process questions. There is no path that straightforward with the FLS. Connor: Core point: The Process question is moot in regards to whether or not we adopt either base or do nothing, I don't think there's a clear win for resolving the process question for either option. (The meeting ended here.) ## Core Library Fit Joel: How does the core/standard library fit into the specification? ## Where should "lowering" from Rust to Minirust go. [Github Issue #57](https://github.com/rust-lang/spec/issues/57)