Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please remove vscode-autohotkey-debug from the pack #1

Closed
zero-plusplus opened this issue Jul 17, 2024 · 5 comments
Closed

Please remove vscode-autohotkey-debug from the pack #1

zero-plusplus opened this issue Jul 17, 2024 · 5 comments

Comments

@zero-plusplus
Copy link

zero-plusplus commented Jul 17, 2024

Hello.
I first noticed that my vscode-autohotkey-debug is included in this pack.

I have no problem with ordinary users packing their favourite extensions.
[Correction started]
Let me just correct myself here.
If someone with influence were to publish an extension pack, the situation I am concerned about could occur. So, I would like to state that I personally do not like my extensions to be included in other people's packs, no matter who they are.

This is not a correction message to mark-wiemer. However, if I edit the message you may be notified. Sorry if that is noise to you.
[Correction ends]

But since you are the same AutoHotKey extension developer, it is a different story.

Because the responsibility of the extension becomes iffy.

For example, the following text in the README.

A collection of VS Code extensions for AutoHotkey v1 and v2 development. This pack is designed to avoid conflicts with multiple extensions.

As can be seen here, an extension pack is just a list of extension IDs. It is not version-controlled to avoid conflicts. This means that this extension pack itself cannot solve future conflict problems.

Any future conflict issues will therefore be resolved by the developers of each of the extensions in the pack. (Of course, AutoHotkey Plus Plus is not an issue here, as you control it.)

I want the responsibility of the extension to be clear and do not like the above state of affairs. So please remove my extension from your extension pack. Also, please add a link to this post in your explanation of why you removed it.

This policy is selfish of me, but thank you in advance.


I use a translator and when it retranslates my sentences it translates them into words that are much stronger than my nuances.

I don't know the fine nuances in English, but I apologise if it contains language that makes you uncomfortable.

@zero-plusplus
Copy link
Author

I also posted a related message here. I feel this one conveys my intentions better, so I'll post the link.

@mark-wiemer
Copy link
Member

Hey @zero-plusplus, I'm just seeing this now, haven't been checking GitHub recently. First off, I hope you can see I've removed your extension from the new v2 release but mentioned it as a recommended one.

I think the responsibility is clear: It's on me as the extension pack author to open issues reporting potential conflicts. I've kept this pack minimal to reduce the likelihood of conflicts in the future, and it doesn't look like thqby's v2 support extension will conflict with your debugger any time in the near future. Given yours and thqby's are the only other extensions planned for the pack, I didn't see much issue saying it was "designed to avoid conflicts with multiple extensions." Note that I as the pack author made this design, and I as the pack author take responsibility for doing what I can to avoid conflicts, even if that means version-locking some extensions in the future, reporting issues, or opening PRs against the other repos.

Ultimately, I hope we can work to create a better developer experience for AHK devs in VS Code. I think your extension is great and I want people to be aware of it. I think they'll understand any minor issues in the short term, and you're welcome to reject conflict resolution proposals for whatever reason. However, I haven't seen many issues and haven't heavily "advertised" this pack yet as I haven't fully tested it myself.

In short, I think adding your extension to this pack will help developers much more than it may harm them, and I'm happy to clarify in the readme that I, the pack author, am responsible for managing conflicts between extensions. I'll also clarify that this pack may not be perfect as it's a group of three extensions supported by independent authors.

I hope this helps. Again, your pack has been removed for now per your request :)

@zero-plusplus
Copy link
Author

zero-plusplus commented Aug 2, 2024

Sorry, my shortcut key misfired and I posted in the middle of the post.


As I mentioned here, there are disadvantages to being included in your extension pack.

Most of all, I do not want my extension to be used in this manner.

Now that my extension has been removed from this extension pack, the liability issue is no longer an issue.
The responsibility for my extension is mine and mine alone and that will not change.

I hope this helps. Again, your pack has been removed for now per your request :)

This is an eternal request.

@mark-wiemer
Copy link
Member

Hey @zero-plusplus, thanks again for writing. I guess we just disagree on some fundamentals, primarily the idea that our extensions are competitors and the value of collaboration. I don't see our extensions as competitors, and I think collaboration would result in both parties learning a lot, but I won't try to change your mind. I won't add your extension to my extension pack per your request.

@zero-plusplus
Copy link
Author

As for the extension pack, this solved the problem. I have posted about the other issues here.

Thank you for your response to resolve this issue. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants