Re: LSC footer for FIDL changes

[Pascal]

+Fuchsia API Council 

What you're describing is more automation around what the API footer (and API +1 flag) is meant to cover, i.e. bring awareness to possibly breaking API changes.

I would think that levering that system which is already established is preferable than creating another one with some of the same rules (as Jeremy mentions), but that will not benefit from improvements planned (e.g. not requiring API +1 for documentation only changes).

Because the LSC process continues to be burdensome (recent retro), requiring this for every API change does not seem feasible. I'd personally like to see more tooling and improvement before we add further friction.

On Mon, Nov 2, 2020 at 5:25 PM Omer Lev-ran <omerl...@google.com> wrote:

On Mon, Nov 2, 2020 at 9:22 AM Jeremy Manson <jeremy...@google.com> wrote:

If you are going to do this, you might make it a bit more finegrained, to stop people having to think about this when they are definitely not making LSCs.

For example, you could exclude .fidl files that aren't in //sdk or are named *.test.fidl.  Those files are not exposed to SDK customers.

You could also check to see whether the corresponding .api file changed, since that excludes a lot of changes that aren't breaking.

Thank you! That helps narrow it down. 

How often are people making FIDL API changes that break SDK customers nowadays, anyway?  I haven't heard of one in a while, although there really isn't much noise being made about why rolls are broken nowadays. 

I will leave this open to @Asif Iqbal to answer as he might know more :)  

Jeremy

On Mon, Nov 2, 2020 at 7:46 AM Omer Lev-ran <omerl...@google.com> wrote:

Hi Pascal,

In go/tq-lsc-streamline we have proposed requiring a LSC footer(similar to bug: or tested: in a commit message for a CL) with a link to a bug when making changes to .fidl files. Below is more details about what this entitles. Wanted to get feedback/suggestions from you.

One question is whether we want to trigger on any .api file changes instead of just changes in a .fidl file.

TL;DR

Any changes to *.fidl files will require an LSC footer. This is either an LSC bug number or a description why this CL is not an LSC.

What is changing?

A new experimental trybot “lsc-check” has been deployed to trigger awareness that a change might require the contributor to go through the LSC process. This is non-blocking for now.

What is an LSC footer?

An LSC footer is similar to the Bug: and Tested: footers in the commit message for a CL. An example is shown below fxr/440265:

What does it mean for change owners?

A contributor making changes to *.fidl files will get a comment on their CL if an LSC footer is missing. The comment the contributor will see is:

This change requires the 'LSC' footer with a link to a bug. If you don't believe this change is an LSC, please add the 'LSC' footer with a description explaining why it is not. See http://go/fuchsia-lsc for additional details.

The contributor can either:

1. Acknowledge and follow the LSC process since the fidl change may cause breakages for downstream customers and the bug number to the LSC footer. 

2. Mark the cl as not an lsc with a justification explaining why it is not an LSC.

 

- Omer