implement utils to check for kernel freshness.

[sayakpaul]

As discussed internally.

I also took the liberty of adding a workflow to check if we always have the KERNEL_SOURCE_MAPPING updated w.r.t the kernels we maintain in the repo. LMK if I should remove it.

[drbh]

looks good just added small nits

[danieldk]

Looks good to me, but the kernel mapping test is failing. We probably should not start with a test that immediately fails. Probably missing entries should be printed, but not lead to test failure.

It would also be nice if this test had a different name, since kernel mapping already has another meaning in the kernels ecosystem (kernel layer mapping).

[danieldk]

Not 100% sure about this one. Ours started diverging - we added our own functions. So, I think it's only loosely based on the vLLM version now.

[sayakpaul]

We probably should not start with a test that immediately fails. Probably missing entries should be printed, but not lead to test failure.

My reasoning here is that when one is adding a kernel source to the repo, if it gets accidentally missed, then we might be missing out on tracking it. IMO, it's better to maintain a mapping for which we don't want to raise any error (like relu). The tests are now failing because we have a missing entry: #285 (comment). I could also add "activation" to the current mapping so that we don't have to check for its "freshness".

While reporting to our internal Slack channels, I can prepare the report such that it clearly indicates which repos haven't been synced and which repos are intentionally skipped.

Does this solution work for you?

It would also be nice if this test had a different name, since kernel mapping already has another meaning in the kernels ecosystem (kernel layer mapping).

Indeed, I will update that.

[danieldk]

We probably should not start with a test that immediately fails. Probably missing entries should be printed, but not lead to test failure.

My reasoning here is that when one is adding a kernel source to the repo, if it gets accidentally missed, then we might be missing out on tracking it. IMO, it's better to maintain a mapping for which we don't want to raise any error (like relu). The tests are now failing because we have a missing entry: #285 (comment). I could also add "activation" to the current mapping so that we don't have to check for its "freshness".

While reporting to our internal Slack channels, I can prepare the report such that it clearly indicates which repos haven't been synced and which repos are intentionally skipped.

Does this solution work for you?

Thanks for the rationale! Opting out explicitly makes sense indeed.

[sayakpaul]

@danieldk I have made the changes as discussed. Additionally, if you could go through the GitHub source repos which we're using for the freshness checks, that would be helpful.

The failing test is unrelated I think?

[MekkCyber]

Niice! just added some entries to the source mapping

[drbh]

lgtm!

[sayakpaul]

Failing tests seem irrelevant to me.