Technical Steering Committee

[lgirdwood]

The SOF technical steering committee is a secret group within GH to allow maintainers from different companies to propose and align on high level architecture and features moving forward. The intention is that proposals can be freely discussed here before being made public with the community.

Things the committee can do :-

1. Propose, discuss and align on architecture.

2. Propose, discuss and align on roadmap.

3. Discuss any opens or unresolved issues and enhancements.

4. Others.

The group is secret and maintainers only to improve the discussion SNR. It's scope will cover all repos hosted under the GH project. e.g. FW, drivers, tools, everything.

[plbossart]

The 'secret' group can't be that secret. There should be clear guidelines on who's invited and all decisions communicated publicly so that the community understands the outcomes. Should be like the Kernel Summit really.

[lgirdwood]

Exactly, all outcomes will be communicated publicly. So far invited is everyone with write access to master or sof-dev and this can be changed or updated in the future (as people come and go). I do expect this will grow as new platforms are added from other companies and at that point we may need to adopt some sort of more formal guidelines, but atm it's just the maintainers. Of course this could be tabled here for discussion.....

[ranj063]

@lgirdwood thanks for sharing this. Just a quick couple of questions regarding the process:

1. How do you normally allow a pull request to be merged? Is there a setting for a minimum number of approvals before the merge button goes green?
2. And when it is indeed green, do you use it ? or do you do it via command line?

[lgirdwood]

So the 2 approvals before merge is only enabled for FW today (since we have 5 maintainers and it's easy enough to get 2 approvals). The driver is set to 0 approvals since this would be up to you and Pierre (and there is only 3 driver maintainers - including me, who doesn't look too often).

There is also an option to forbid merging unless all CI passes, not enabled yet since CI can still be a bit flaky but maybe something we should consider when things are running more smoothly.

[jajanusz]

@lgirdwood AFAIK we had rule that we usually wait at least 24h from creation of PR to merging, to give reviewers chance to say that something's wrong. Is it rule still valid or now we merge as soon as we get 2 approvals (assuming there were no Changes requested before) ?

[lgirdwood]

In general always best to give a working day, especially for invasive patches or patches that touch critical subsystems. This gives everyone a chance to comment as someone may report some issues with the PR. Simple and obvious bug fixes to non critical subsystems on the other hand can go quicker.
Golden rule is "what impact does the PR have if it's broken".

[jajanusz]

So the 2 approvals before merge is only enabled for FW today (since we have 5 maintainers and it's easy enough to get 2 approvals). The driver is set to 0 approvals since this would be up to you and Pierre (and there is only 3 driver maintainers - including me, who doesn't look too often).

It sounds like we should have 2 approvals from maintainers, but actually we are able to merge when there are 2 approvals from anyone, should it be like this or it's just limitation of GH settings and we have to look who gave these approvals?

[lgirdwood]

@jajanusz lets check the settings, iirc reviewers/approvers can be anyone in sof-developers i.e with issue/git W access. I'm travelling atm so if you find any article that explain how to configure "approve" reviewers let me know and I'll take a read. Fwiw, I'm not against developers reviewing, it makes them better developers and we still always need a maintainer to click merge.