Roadmap: move plugins

[mast-eu]

Scope

Move plugins from Git Extensions main repo into their own repos (#5574).

Step 1) Preparation

Mandatory things that need to be clarified or done before we can actually start relocating the plugins.

• Review plugin interfaces and publish as NuGet package (Review plugin API and publish as NuGet package #6624)
  ❗️ All plugins must include this as dependency and link against it.
• switch to compile-time XLF tool and reduce human intervention for updating translations (Research compile-time XLF tools #5189)
• Integrate PluginManager (https://github.com/maraf/GitExtensions.PluginManager)
  • merge code (Issue 4885 - Integration of PluginManager #5775 / Plugin distribution #4885)
  • Plugin installation path (Loading user plugins from app data folder. #6551 / Plugin installation path #6415)
  • ship PluginManager as part of a release (Reintegration of PluginManager. #6664)
• Test deployment, installation, execution, update and removal of a simple plugin through PluginManager.
  💡 I'm currently working on https://github.com/mast-eu/GitExtensions.SVN, which will probably be the first (public) NuGet-based plugin and should be a good candidate for these tests.
• ❔ Who will be the owner of the plugins' repos and the publisher of the NuGet packages?
• ❓ Has the plugin relocation any impact on the GE relicensing process (Relicense request #4737)?

Step 2.a) Move plugins out

Start with the "easier" plugins, i.e. those who do not have specific settings (less contact points with GE).

• Create local tracking branches
• Gerrit Code Review
• GitFlow
• Impact Graph
• Release Notes Generator

Move the remaining plugins in a second round (maybe tackling #5797 as well).

• Auto compile SubModules
• Bitbucket Server
• Delete obsolete branches
• Find large files (open PR Plugins/FindLargeFiles: Fix a bug when files to be deleted have spaces in its name #4669)
• GitHub
• Gource
• Jira Commit Hint (open PR Allow usage of custom fields in jira commit hint plugin #6294)
• Periodic background fetch
• Proxy switcher
• Statistics
• Build server integration TeamCity
• Build server integration AppVeyor
• Build server integration Azure DevOps and Team Foundation Server >= 2015
• Build server integration Jenkins
• Build server integration Team Foundation Server

For each plugin do:

1. Extract current plugin code "as is" from GE, wrap it as NuGet package and push to it's own repo. Do not remove it from the main repo yet.
2. Publish NuGet package on nuget.org and mark the embedded plugin as deprecated in next feature release of GE.
   ❗️ There should always be at least one GE feature release with the embedded plugin marked as deprecated and the NuGet-based counter-part already available to allow a smooth transition.
3. Get some core and community members to verify whether the embedded and the NuGet-based have the same functionality.
4. Move existing issues into plugin-specific issue tracker. Go through this list.
5. Fully remove embedded plugin with next feature release of GE (code, resources, unit tests, installer, documentation?, etc).

Step 2.b) Improvements to GE and it's plugin API

Things that are not necessary (strictly speaking), but will facilitate the work, make the implementation more robust and improve maintainability.

• Write unit tests for all API methods (if not already done), to ensure they will not be accidentally modified.
• Improve the existing API and extend it as necessary.
  • make items in Plugins menu optional (Plugins - Jira hint: No response #6484)
• How to handle bugs in plugins? (How to handle bugs in plugins? #6523)
  • Plugins source code base URL (Plugins source code base URL #6543)
  • Extend the current environment info to contain a list of all loaded plugins and their version numbers
  • Implement a kind of "safe mode" to (re-)start GE without plugins
• PluginSettings key names (PluginSettings key names #5797)

Step 3) Evolution of existing plugins and development of new ones

Ideally, this will be community-driven.

Some ideas for new plugins are already floating around:

• Create plugin to wrap git-ftp (Create plugin to wrap git-ftp #5382)
• Plugin: Octopus Deploy (Plugin: Octopus Deploy #5254)

[mast-eu]

I will update the roadmap as things evolve to always reflect the current status.

@gitextensions/git-extensions-source : Obviously any kind of feedback is much appreciated, but in particular I would like to discuss these open questions:

• Who will be the owner of the plugins' repos and the publisher of the NuGet packages?
• Has the plugin relocation any impact on the GE relicensing process (Relicense request #4737)?

@maraf : What do you think?

[maraf]

@mast-eu I agree with you in all points.

About plugin ownership, it think that plugin author should be also the owner of the repo and the nuget package. Current "default" plugins could stay under gitextensions org.

[gerhardol]

Current "default" plugins could stay under gitextensions org.

and be transferred if someone else takes responsibility

[RussKie]

Few points

• Plugin author is an owner of a plugin
• Ideally Git Extensions team should be a co-owner - in event the author abandons a plugin or there is a vulnerability we must be able to step in
• We would transfer a plugin ownership to a party interested in maintaining it

[mast-eu]

Ok, seems so far we all (including myself) agree on:

1. New plugins are owned and published directly by its author.
2. Existing GE plugins will start their life under Git Extensions team ownership.
3. Transfer of ownership should be possible somehow. I'll think about it.

in event the author abandons a plugin or there is a vulnerability we must be able to step in

How about giving GE the ability to blacklist plugins? This way we could block abandoned plugins.

[RussKie]

How about giving GE the ability to blacklist plugins? This way we could block abandoned plugins.

I'm not sure it is feasible. This would require a centralised directory of approved plugins (think of a plugin store).
Otherwise a bad actor may publish a different plugin...

It is a user's responsibility to exercise caution and due diligence when using software downloaded from internet.

[mast-eu]

How about giving GE the ability to blacklist plugins? This way we could block abandoned plugins.

I'm not sure it is feasible. This would require a centralised directory of approved plugins (think of a plugin store).

Actually, I was thinking of a blacklist contained in the GE release itself (i.e a file with GUIDs or base URLs or something else to uniquely identify plugins), rather than of a centralised directory.
However, thinking further i now agree it is not the right way. In this scenario blacklisting a plugin would always require to release a new version of GE with the updated blacklist file.

[mast-eu]

GitHub has just announced the launch of their own package management service. It's called GitHub Package Registry and supports, among others, also NuGet.
It's still beta, so too early to judge seriously, but it might become an interesting alternative to nuget.org. I will keep an eye on it.

[mast-eu]

Found a few issues and PRs that might become blocking:

• Research compile-time XLF tools #5189: Switch to a compile-time XLF tool. Most (all?) plugins have localized strings, too. I wouldn't like to duplicate the TranslationApp and the current mechanism to update XLF files in all these repos. I'd rather prefer to set them up with some compile-time tool right from the start.
  @RussKie: What do you think? I consider this one quite urgent. I suppose you didn't have time yet to look deeper into XLF tools, right? If it's ok for you, I will start working on this issue.
• WIP #6294: Allow usage of custom fields in jira commit hint plugin #6295: open PR on Jira Commit Hint. Should get merged before moving this plugin.
• Plugins/FindLargeFiles: Fix a bug when files to be deleted have spaces in its name #4669: open PR on Find large files. There hasn't been any activity in more than 1 year, I just pinged the author to see if he's still interested.

[RussKie]

• Research compile-time XLF tools #5189: Switch to a compile-time XLF tool. Most (all?) plugins have localized strings, too. I wouldn't like to duplicate the TranslationApp and the current mechanism to update XLF files in all these repos. I'd rather prefer to set them up with some compile-time tool right from the start.
  @RussKie: What do you think? I consider this one quite urgent. I suppose you didn't have time yet to look deeper into XLF tools, right? If it's ok for you, I will start working on this issue.

I'm doing some what in this area, but I'm happy to share 😉 Let's continue the discussion in #5189.

• WIP #6294: Allow usage of custom fields in jira commit hint plugin #6295: open PR on Jira Commit Hint. Should get merged before moving this plugin.

Sure. But it can equally be redirected to a different repo, if necessary

• Plugins/FindLargeFiles: Fix a bug when files to be deleted have spaces in its name #4669: open PR on Find large files. There hasn't been any activity in more than 1 year, I just pinged the author to see if he's still interested.

ditto.

I think before we can start moving any plugins we need to define a public plugin contract. This would involve moving and publishing GitUIPluginInterfaces project as a package.
To do that, we need to review IGitModule and all other interfaces - should they be there, do they have all necessary definitions and so on.
I would also like to rename GitUIPluginInterfaces to something like GitExtensions.Plugins.Interfaces (open to ideas).

[mast-eu]

I've updated the roadmap, in particular:

• Review plugin interfaces and publish as NuGet package (Review plugin API and publish as NuGet package #6624)
• switch to compile-time XLF tool and reduce human intervention for updating translations (Research compile-time XLF tools #5189)

As these are the next issues to be tackled.
They should be mostly independent, so discussions can be done directly in the respective issues.
I write "mostly independent", because probably each plugin should have it's own XLF file containing localisations. Thus the plugin API must support this scenario as well.