Re: [S] Change in fuchsia/fuchsia[main]: [areas] Suggest "Language Runtimes" area
1 view
Skip to first unread message
Hunter Freyer
Jan 26, 2023, 11:23:52 AM1/26/23
to Yifei Teng, eng-c...@fuchsia.dev, Jeremy Manson, api-council
Note that what you've proposed in the CL is actually an RFC Area, not an API Council area. RFC Areas are a superset of API Council areas, and don't have as strong a notion of "ownership" as API areas do. As Jeremey points out, it'd be difficult to nail down one owner to review all changes related to "Languages and Libraries", but as an RFC area, I think that's fine.
Thanks,
Hunter
On Wed, Jan 25, 2023 at 6:56 PM 'Yifei Teng' via api-council <api-c...@fuchsia.dev> wrote:
I'll update my CL to use "Core Libraries".--On Tue, Jan 24, 2023 at 11:13 PM Yifei Teng <yif...@google.com> wrote:Core Libraries sounds like a much more accurate fit to the things I'm working on e.g. libraries for idiomatic async programming.On Tue, Jan 24, 2023 at 10:48 PM Jeremy Manson <jeremy...@google.com> wrote:If this is about use of the language, I probably wouldn't use Language Runtime. If I see "Language Runtime" related to C++, I tend to think specifically of the stuff in the linker, libc, libstdc++ / libc++, etc, and not holistically about its use in a program.If it is about that stuff, I'd probably use "Toolchain".You might also use "Developer", which we've used in the past in the glossary mostly for higher level stuff like build systems and system assembly, and in the rest of the world for the SDK and tooling, but I could see applying here as well.If this is specifically related to a library we wrote instead of a feature of the language or in the C++ standard libraries, perhaps something like Standard or Core Libraries might be a better choice. Typically, areas imply some level of ownership, and I'm not sure who would own "Language Runtime" as you are using it, but I could imagine a few people who could own Core Libraries.JeremyOn Tue, Jan 24, 2023 at 1:42 PM 'Yifei Teng' via api-council <api-c...@fuchsia.dev> wrote:Hi API Council,--I wanted to document a glossary specific to Fuchsia's use of async C++. But I found it difficult to specify an appropriate area, which was required by the glossary page. The fuchsia.dev glossary guide suggested that I can propose a new area. I picked the term "Language Runtimes" since one might also want to document Rust specific terminologies down the road. What does the council think? (c.f. CL: fxrev.dev/790883) Thanks!Cheers,Yifei---------- Forwarded message ---------
From: Benjamin Lerman (Gerrit) <noreply-gerritcodereview-d7rgCbDJaF-IIGU_g3Xkvg==@google.com>
Date: Fri, Jan 20, 2023 at 1:39 AM
Subject: [S] Change in fuchsia/fuchsia[main]: [areas] Suggest "Language Runtimes" area
To: Yifei Teng <yif...@google.com>
Cc: Nick Van der Auwermeulen <nickv...@google.com>Attention is currently required from: Nick Van der Auwermeulen, Yifei Teng.
Patch set 2:Code-Review +1
1 comment:
Patchset:
Sounds good to me, but I wonder if there should be a mail to the API council list first?
To view, visit change 790883. To unsubscribe, or for help writing mail filters, visit settings.
You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CANbn4XBK6Aio%2BhibAAhR%2Bfzoc5FvxWjD3SpFdZcxiLueCR%3DE8A%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CANbn4XC_3pwn1KM0BSTHnv57i%3DSJgh0-%2B6TeB-rhhhPB3iV5FA%40mail.gmail.com.
Yifei Teng
Jan 26, 2023, 1:18:32 PM1/26/23
to Hunter Freyer, eng-c...@fuchsia.dev, Jeremy Manson, api-council
On Thu, Jan 26, 2023 at 8:23 AM Hunter Freyer <hjfr...@google.com> wrote:
Just to bikeshed for a moment: how about "Languages and Libraries"? We've got a Python RFC incoming; RFC-0193 dropped support for C++14 and affirmed support for C++17; I could imagine future RFCs saying things like "$CONTRVERSIAL_LANGUAGE_FEATURE is banned". All those examples stray outside the bounds of "Core Libraries" but aren't necessarily "Toolchain" either.
Sounds good to me. Thanks for the suggestion!
Note that what you've proposed in the CL is actually an RFC Area, not an API Council area. RFC Areas are a superset of API Council areas, and don't have as strong a notion of "ownership" as API areas do. As Jeremey points out, it'd be difficult to nail down one owner to review all changes related to "Languages and Libraries", but as an RFC area, I think that's fine.
Gotcha. To clarify, is the API Council area encoded in `docs/contribute/governance/areas/_areas.yaml`? It has a TODO implying those two areas should be aligned but perhaps they should be intentionally different (RFC⊃API) as you pointed out.
Hunter Freyer
Jan 26, 2023, 4:08:16 PM1/26/23
to Yifei Teng, eng-c...@fuchsia.dev, Jeremy Manson, api-council
On Thu, Jan 26, 2023 at 1:18 PM Yifei Teng <yif...@google.com> wrote:
On Thu, Jan 26, 2023 at 8:23 AM Hunter Freyer <hjfr...@google.com> wrote:Just to bikeshed for a moment: how about "Languages and Libraries"? We've got a Python RFC incoming; RFC-0193 dropped support for C++14 and affirmed support for C++17; I could imagine future RFCs saying things like "$CONTRVERSIAL_LANGUAGE_FEATURE is banned". All those examples stray outside the bounds of "Core Libraries" but aren't necessarily "Toolchain" either.Sounds good to me. Thanks for the suggestion!Note that what you've proposed in the CL is actually an RFC Area, not an API Council area. RFC Areas are a superset of API Council areas, and don't have as strong a notion of "ownership" as API areas do. As Jeremey points out, it'd be difficult to nail down one owner to review all changes related to "Languages and Libraries", but as an RFC area, I think that's fine.Gotcha. To clarify, is the API Council area encoded in `docs/contribute/governance/areas/_areas.yaml`? It has a TODO implying those two areas should be aligned but perhaps they should be intentionally different (RFC⊃API) as you pointed out.
I was about to say, "what do you mean? I wrote a CL last week that fixed that!" Turns out, writing a CL isn't the same as submitting a CL...
Reply all
Reply to author
Forward
0 new messages