Add Bugsink as a "consumer" to debug-id.md

[vanschelven]

No description provided.

[vanschelven]

I did read the contributing guidelines, and realize that those state that to contribute, I'd need to join the TC;

happy to do that if indeed required; for now I'm just leaving this here "out of order", as I imagine that the single act of documenting the existence of a consumer of debug IDs may not have such strict requirements, or otherwise, someone who is on the TC is willing to "sponsor" this PR.

[lforst]

I am technically the champion of this proposal, and I welcome anybody in support of it, but I think I have a bit of a conflict of interest here.

I would personally be okay with adding Bugsink as a consumer if you can guarantee that your backend does not simply re-use Sentry code (i.e. symbolicator or the Sentry backend). All of the tools in the blog post you linked are Sentry tools, and unless your backend has a different implementation, it would feel wrong to list Bugsink, as it would just be all the same tooling with a different name, which would be dishonest to anybody reading and signing off on the proposal.

Since I have a conflict of interest, I will defer to other TC39 members for this one.

[vanschelven]

simply re-use Sentry code [..] symbolicator [..] Sentry backend [..] Sentry tools

I get the point; let's leave the weighing of that point to other TC39 members. In the meantime I'll answer.

• for the injection of Debug IDs, Bugsink relies entirely on other (Sentry) tools, in particular on sentry-cli
• for the consumption of the Debug IDs, there is no external dependency at all, Bugsink simply has its own implementation of this functionality. Given the header "Consumers/Debuggers" I'd argue this is the relevant fact 😄

for completeness: for sourcemaps parsing, Bugsink does not rely on symbolicator, although it currently does rely on another Open Source library

[lforst]

I see! Considering that the Bugsink backend has a different implementation as consumer I am fine with adding it to the list :)

[nicolo-ribaudo]

I was also a little bit conflicted about this, for a different reason: I don't want proposals to just become a list of "advertisement" for products. It's good however to show that there are multiple real-world use cases for the proposal, and that it's not just Sentry doing their own thing.

That said, a list containing two links is far from being what I consider problematic :P

I'll merge this pr as @lforst approved it. Luca, I'll give you write access to the repo so that you can merge PRs related to DebugID.