How to add a slot for power functional area?

[Hai Bi]

I was advised to ask if power can be granted an API reviewer slot. Is this the right contact?

[Hunter Freyer]

This is the right contact!

Per the API Council charter:

When considering adding an area, the council considers:

1. Coverage. Is this area already covered by one of the other areas, or is there a gap?
2. Scope. Is this area sufficiently large to warrant a dedicated appointee?
3. Consistent need. Has the need to have this as an area arisen before?

I could believe that "Power" meets these criteria, but maybe you can give us some more flavor for the kinds of APIs that would fall under this area?

Thanks,

Hunter

On Wed, Aug 9, 2023 at 5:30 PM 'Hai Bi' via api-council <api-c...@fuchsia.dev> wrote:

I was advised to ask if power can be granted an API reviewer slot. Is this the right contact?

--
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/CA%2BMMcTRuMBU7B%2BPMQ%3DCvH5t%2BvFNFN%2BYo9BNbLupfPe2SQQ4yFQ%40mail.gmail.com.

[Onath Dillinger]

Thanks for the response, Hunter. Here's my brief take:

1. Coverage. Is this area already covered by one of the other areas, or is there a gap?

Power is not covered by any existing functional area; distinct examples of API needs include:

Existing:

- Thermal management

- System power modes

- Power source management

Upcoming

- Power topology

- Suspend/resume

- Power delivery

2. Scope. Is this area sufficiently large to warrant a dedicated appointee?

Yes. Power APIs are tasked with providing tractable ways to manage a wide variety of subsystems at a high-level scope. They require a detailed understanding of common patterns that emerge across many different functional areas.

 

3. Consistent need. Has the need to have this as an area arisen before?

The existing fuchsia.power FIDL namespace (https://cs.opensource.google/search?q=file:fidl%20file:sdk%2Ffidl%2Ffuchsia%5C.power&ss=fuchsia%2Ffuchsia) is a good example of APIs that generally could have used designation in this functional area. In practice, our needs previously emerged slowly enough that we could get peripheral coverage from reviewers in other areas, working outside of their strict bounds. The recent acceleration of the power effort, however, calls for explicit council coverage.

Cheers,

Onath

[Hunter Freyer]

This all sounds reasonable. 

API Council Members: as an experiment, I've sent y'all a ballot to get a proper vote on this. As per the API Council Charter, the threshold for acceptance is "rough consensus", not a strict vote count. But I'd still like to get a positive signal, rather than assuming "silence is agreement."

PTAL soon! It's very quick.

Thanks,

Hunter

[Hunter Freyer]

Friendly ping to API Council members! We've got 6 responses so far but we can do better than that!

[Hunter Freyer]

tl;dr: Yes to Power API area. Council Members: vote here on @Michael Brunson's addition to the API council!

Okay, looks like we have a result here!

There was unanimous support for adding a Power area. Most respondents thought "Performance" was not a part of "Power", and 2/3 thought "Thermals" was a part of "Power", but nobody liked putting "Thermals" in the name. 

So, in sum: we'll add a "Power" API Area, and the "Thermals" APIs will be considered a part of that unless/until we come up with some reason for it to be elsewhere.

In terms of the Area Owner, everyone was comfortable with @Eric Holland, but when I contacted him offline, he nominated @Michael Brunson instead. I've set up another vote to collect support or concerns for his nomination. Council members! Vote!

@Onath Dillinger, while we collect feedback on this, would you mind writing up some text for the Power API Area to include in the documentation?

Thanks,

Hunter

[Onath (Claridge) Dillinger]

Thank you, Hunter! I'll be happy to write up an area description.

Cheers,

Onath

[Hunter Freyer]

Reminder to API Council members! Vote here! There's only 4 responses so far - I know we can do better.

Or I could always replace these super quick and easy forms with a recurring meeting on all y'alls calendars...

Thanks,

Hunter

[Onath (Claridge) Dillinger]

Thanks for your patience -- please find an area description below.

Cheers,

Onath

The set of APIs for centralized power and thermal management, including system power state control, administration of power dependencies, and thermal throttling. Also includes aspects of power delivery such as battery management.

Naturally overlaps with other API areas on power/thermal-related drivers and subsystem-specific power management APIs. Ownership of overlapping APIs is deferred to other API areas where practical, with the Power area operating in a consulting role.

Examples:

• fuchsia.power.battery

• fuchsia.power.systemmode

• fuchsia.thermal

[Hunter Freyer]

Fantastic, thank you!

Separately, Michael's candidacy for area owner has been approved by the API council! I'll prepare a CL adding Michael to the relevant files, and will send it to him. He can indicate his acceptance of the responsibility by +2ing.

Thanks everyone for helping out! I know this was an annoyingly slow process, but I'm going to blame that on summer vacations, rather than my own procrastination... Yeah, that sounds right :P

Hunter

[Michael Brunson]

Thanks for organizing and keeping everyone informed, Hunter...even if those pesky summer vacations slowed things down. 🙂

--

Michael T. Brunson, II mbrunson@google.com Software Engineer 1600 Amphitheatre Pkwy, Mountain View, CA 94043 Attn mbrunson