promote builtin-related issues on plugins to P1

[gattytto]

as mentioned in the last call
https://docs.google.com/document/d/1duuavOXVAJNbzU8nIltraDKx5YH2Z34Qwx7AeLnhhzU/edit

this issue is to request the P1 priority to issues about new ms-vscode plugins to plug-registry when their implementation requieres a missing (due to being conflicting or unimplemented) builtin in theia.

the process of adding ms-vscode plugins to the plugin registry has been improved a lot and the only blocker I can see so far (that I can't overcome myself by editing the dockerfiles/.vsix sources) is this.

for example:
issue for adding vueJS plugin to che: #13672
the extension gives an error because of the following issue:
eclipse-theia/theia#6623 (comment)

so for conclussion, promoting this issues when the builtin situation arrives would shorten the times in which the users can keep contributing to the new plugins implementations

[ibuziuk]

@gattytto I was not able to attend the last call, so do not know the outcome of the discussion atm. However, the biggest question for me is who is expected to work on those P1s? Does the community members ready to kick on and contribute the missing bits to theia and own the newly contributed plugins?

[tsmaeder]

@gattytto not sure what you mean by "built-in". Do you mean VS Code API or a built-in extension?

[sunix]

@ibuziuk last call @gattytto had a mic problem. We postponed discussion to next monday.

[gattytto]

@tsmaeder what I mean with "builtins" is the vs-code built-in extensions as of this: #14759

@ibuziuk what I mean is that there is more complexity to the theia API and builtin extensions so users may encounter known issues with builtins while trying to add a .vsix extension to the plugin registry.

In the case of html-language-features (which is a built-in required by the vuejs extension) it was enough just by adding the html-language-features.vsix prior to the loading of the vuejs extension but there may be cases in which built-ins conflict with each-other or .vsix versions of the ms-vscode builtins are outdated.

So this represents a blocker for a user trying to just make a sidecar container (and maybe a cli one too), and some extension's meta.yaml to add a ms-vscode extension to che. In this case maybe it would be nice to have P1 on this case to get help from che devs around it so users can continue their work

[gattytto]

@ibuziuk last call @gattytto had a mic problem. We postponed discussion to next monday.

yes I was unable to speak to the mic so I just added the subject to the topics and it was postponed to the next session. Gladly I have fixed my mic problems now and I'll be able to speak with you all next time

[gattytto]

this is an example of the situation, the original ms-vscode/vscode-github-pullrequest/latest/meta.yaml has this:

spec:
  extensions:
  - https://github.com/microsoft/vscode-pull-request-github/releases/download/v0.8.0/vscode-pull-request-github-0.8.0.vsix

and changing that for:

spec:
  extensions:
  - https://github.com/microsoft/vscode-pull-request-github/releases/download/0.14.0/vscode-pull-request-github-0.14.0.vsix

as mentioned in the issue, an error about an unimplemented method appears.
#16283

[gattytto]

this one is very recent too #16341

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[ericwill]

We are working on upgrading all plugins (built-ins and vsix's) to the latest version. Theia API needed for those will be handled on a case by case basis.

I'm going to close this, and we can handle the specific problems in their own issues.