Moving the the language server plugins to prometheus-community

[slrtbtfs]

The PromQL language server is a back end for providing IDE like features for PromQL.

Currently there exist two Plugins that integrate the PromQL language server with a text editor.

• https://github.com/redhat-developer/vscode-promql (for VS Code)
• https://github.com/nevill/lsp-promql (for Sublime Text)

For consistency reasons it would make sense to have both of these projects somewhere in promtheus-community. This also likely would simplify the legal situation around using Prometheus trademarks and branding.

The current owners of these projects seem to be willing to donate those to prometheus-community.

To move these projects to prometheus-community there are basically two options:

• Moving the repos to the prometheus-community org.
• Putting everything in the promql-langserver repo. This mono repo approach would provide the advantage of simplifying the release process, changes that need to happen both on the extension and on the server side and the creation of integration tests.

cc @krasi-georgiev @brancz @squat @juliusv @sym3tri @ant31 @nevill @nexucis

[brancz]

Happy to sponsor this on the prometheus-community side.

[nevill]

Thanks @slrtbtfs for invitation. I'd like to donate nevill/lsp-promql to the community.

PS, I am not sure if LSP-promql will work in a mono repo, because package control will automatically grab the latest version and publish it. I guess it has some directory structure requirements there.

[slrtbtfs]

PS, I am not sure if LSP-promql will work in a mono repo, because package control will automatically grab the latest version and publish it. I guess it has some directory structure requirements there.

Sublime docs say no to mono repo:

Only include one package per repository and be sure the root of the package is the root of the repository.

[slrtbtfs]

Having a mix between a mono and poly (is that the right word) repo, doesn't sound great either, so for now I'm leaning more towards just changing repo ownership.

[Nexucis]

Yeah np.

1. One thing that would be great is to be able to cathegorize the different repository in the prometheus-community. I mean instead of having a list of random repository you would have a kind of sub organization.

For example:

• prometheus-community/promql-repo/ and you would have the promql-server; monaco-promql; lsp-promql and so one
• prometheus-community/exporters/ like stackdriver_exporter

Just in order to have a clear view of the different repo. In Gitlab if I remember well it was possible, but not sure it's feasible in Github.

2. Also I think the repo nevill/lsp-promql should be rename to sublime-text-promql or something like that in order to avoid a confusion with the repo promql-langserver

[slrtbtfs]

In Gitlab if I remember well it was possible, but not sure it's feasible in Github.

I'm quite sure GitHub doesn't have that feature.

What could be done, is to give all that tooling around PromQL a consistent naming scheme, i.e. having a promql-langserver and a couple of promql-<editorname> repos.

[brancz]

What could be done, is to give all that tooling around PromQL a consistent naming scheme, i.e. having a promql-langserver and a couple of promql- repos.

I think this is feasible as a start, should this explode then there could be a separate org just for this purpose.

[slrtbtfs]

@brancz Could you take care of moving the VS Code extension from redhat-developers? Since I'm not working at Red Hat any more I can't do this myself.

[squat]

I have admin privileges in the repo and can initiate the transfer.

-Lucas

On Mon, Jul 6, 2020 at 12:59 AM Tobias Guggenmos notifications@github.com wrote:

@brancz https://github.com/brancz Could you take care of moving the VS Code extension from redhat-developers? Since I'm not working at Red Hat any more I can't do this myself.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prometheus-community/community/issues/27#issuecomment-653949679, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE4JAP3FDISLSOY7XCCAIJLR2EATVANCNFSM4OLINYAA .

[brancz]

@squat can you give me sufficient access so I can move it? Otherwise we can coordinate tomorrow so I give you temporarily permissions to move it to this org.

[nevill]

@brancz I also need a temporary permission to transfer, I can do it at July 11, 2020 UTC.

[brancz]

@nevill could you just invite me to your repo so I can do the move? I'll remove myself from the repo afterwards.

[nevill]

OK @brancz, I didn't know if a collaborator can transfer the ownership. Invitation has been sent anyway.

[Nexucis]

he will need the admin right for that. Just beeing a collaborator won't be enough.

[brancz]

Yeah, came here because I tried moving and I don't have sufficient permissions. As a side note I imagine we are going to want to rename the repo to maybe sublime-promql (just because it's kind of confusing to have "lsp-promql" and "promql-langserver" in the same org)? I won't do this, I'll let you decide, just a suggestion, but I will need more permissions to perform the move.

[Nexucis]

well another way to do it is just creating an empty repo here with the appropriate name, give nevill write access to it and then he can push all commit and tag inside the new fancy repo. It's maybe simpler like that no ?

[slrtbtfs]

IIRC from moving promql-langserver, admin rights for others aren't possible with personal repos.

[nevill]

I don't want to rename the package name LSP-promql, to follow the LSP plugin naming convention, even some of the infamous packages indeed don't follow the convention. It's a good name to let people find it easily. LSP is short for Language Server Protocol, not Language Server, BTW. If we change project name to sublime-promql, but package name stays, it also makes me itchy. 🤔

[nevill]

well another way to do it is just creating an empty repo here with the appropriate name, give nevill write access to it and then he can push all commit and tag inside the new fancy repo. It's maybe simpler like that no ?

Thanks, I can accept this way. But the most simple way is just fork my repo, if I don't transfer the ownership. By bothways, the only thing we missed is the old issues, but luckily we have only one there in the history.

[Nexucis]

(just because it's kind of confusing to have "lsp-promql" and "promql-langserver" in the same org)

I'm in favor of renaming it for this reason.

And you can change the package as well and saying in the readme there is a breaking change. Like we did for monaco and codeMirror.

[nevill]

Why it's confusing to have LSP-promql and promql-langserver at same time? Even as I explained the abbreviation? We can also states the usage in the README, and actually we did.

[nevill]

@brancz I can accept all the ways we mentioned above in this issue to transfer the ownership. And I think transfer it by myself is the ideal way, but there's a trust issue. So I may have @krasi-georgiev as my reference to gain the write permission of the org.

[Nexucis]

It's confusing, because when you are reading you cannot directly understand that's the client side. The name of a projet should describe what does it do. Basically behind lsp-promql it could be the implementation of the lsp for promQL (server side) or something else. There is nothing that can tell it is a client implementation for sublime text. Basically I could also put behind the implementation for vscode

[Nexucis]

And if every client implementation is going to do the same, in one week we will have these projets:

• lsp-promql
• promql-lsp
• my-awesome-lsp-for-promql
• lsp-is-so-cool-promql

That's why for the client plugin that provides a support for promQL, there should be a naming convention for the project's name. For example:

-lsp-promql. Like vscode-lsp-promq

[juliusv]

If it's Sublime-specific, but doesn't live in a GitHub organization that is Sublime-specific by itself, then definitely it needs to include something about Sublime in its name.

[nevill]

OK, I think if a developer happened to browse the project list, prefix with sublime makes it clear. How about rename the project to SublimeLSP-promql? To honor github.com/sublimelsp. Also, I don't want to have 2 dashes in the name. 😺

[brancz]

I think I can live with sublimelsp-promql. If that name sounds good, then I can create the repo as an empty repo, give you write access and you push everything into it.

[nevill]

@brancz thanks. but can you ping @krasi-georgiev or wait for a moment? I really want to try transfer the ownership if possible. :)

[brancz]

@krasi-georgiev is on vacation. He's part of my team, so if you trust him you trust me :) (also I have admin permissions on this entire org so you're going to need to trust me either way)

[nevill]

OK @brancz, let's go the way you suggested.

[brancz]

Created the https://github.com/prometheus-community/sublimelsp-promql repo and added the sublimelsp-promql team as maintainers, and added you @nevill to that team. You can go ahead and push to the repo :)

[slrtbtfs]

Looks like @prombot tried to create a PR there before anyone pushed to another branch and now repo_sync has become the default branch.

[slrtbtfs]

Btw, @brancz what's the status of moving the VS Code extension?

[roidelapluie]

Fixed default branch

[nevill]

Once package_control_channel accepts my PR, my move is complete. Thank you all for help. 🎉

[brancz]

@squat is on vacation, so moving the VC Code extension will need to wait until he's back as I don't have the permissions. Once he's back we can perform the move.

[slrtbtfs]

@squat I'd assume the aforementioned vacation is over now. Would it be possible to perform that repo move soonish?

[simonpasquier]

@slrtbtfs @Nexucis I've been granted admin permissions on https://github.com/redhat-developer/vscode-promql so I should be able to transfer the repository to the prometheus-community organization. I'm also happy to sponsor the project. What would be the name of the new repository? vscode-promql, vscodelsp-promql or something else?

[slrtbtfs]

Thanks for finally bringing this effort forward on the Red Hat side.

I don't have strong opinions about naming and am fine with vscode-promql.

[Nexucis]

yeah vscode-promql is ok @simonpasquier

[simonpasquier]

the migration is done.

[slrtbtfs]

Great, thanks!