Addon development improvements

[DavidMStraub]

Using this comment by @Nick-Hall to start a new topic:

@Nick-Hall

There isn’t really a process for releasing addons. In the past we have left it to individual developers. The actual publication of an addon has to be performed by a trusted developer. This is to guard against malicious code.

I’m currently working on a new Addons Manager and a new presentation for addons in the wiki. We could also consider suggestions to improve the release process.

My suggestion would be to use an approach similar to HACS (Home Assistant) or Nextcloud: each addon lives in a separate Github repository (based on a template provided by the Gramps project that can be cloned to start addon development) and the addon maintainer is responsible for maintaining the repository and creating tags.

Then there are two options:

1. There is no official endorsement of addons, so users must manually add Github repositories as “addon sources”. Advantages: no review required, risk is transparent to the user (no false sense of security of using “endorsed” apps), fast workflow. Disadvantages: no review done, possibly difficult for users to find addons.
2. Addon owners must get their repository approved once. Advantages: official list of addons (as it is now), review is possible. Disadvantages: review required which makes it slower.

The second option would still be better than today as it would not require approval of every single changem which IMO makes maintaining & improving an addon painful.

[Mattkmmr]

Personally I’d prefer option 1 since it is the fastest way to publish new addons. This workflow would also reduce the amount of code Gramps developers have to maintain. Disadvantages like “difficult for users to find addons” can be reduced by users maintaining lists of addons on the Gramps wiki or elsewhere.

[emyoulation]

In a parallel vein, Kari Kujansuu @kku implemented a ZipInstall… tool that will install into the gramps51/plugins folder a ZIP downloaded when GitHub generates after choosing “Download ZIP” from the repository’s <> Code button (or ZIPs that have been eMailed).

This tool opens a GtkFileChooser dialog. That dialog has a button for navigating to the “Downloads” folder for Windoze. Hopefully, an equivalent button existing for Linux and macOS.

(In a conversation earlier this year, Kari wrote that the tool does not handle the .tgz compressed files served to the Gramps add-on manager and which we currently link from the Addon List on the wiki page. However, the GtkFileChooser filter lists .zip files and .tgz files in addition to Supported files option.)

A Tool like this needs to be in the Gramps core plugins. It provides a Workaround option.

[Nick-Hall]

@emyoulation

A Tool like this needs to be in the Gramps core plugins.

I can add this functionality to the new Addon Manager. I think that there was something similar in the old Plugin Manager.

[emyoulation]

Here’s a capture of the confirmation dialog that appears for Kari’s ZipInstall after selecting a download (from my GitHub repository) with a matching registered version (Sometimes, the version numbers in the .gpr.py are not updated with a minor tweak. So a user will want to overwrite despite that.):

Followed by a confirmation:

Note: the overwrite install with no backup took quite a bit longer than expected.

[emyoulation]

I have a noob question about tweaking plugins. I see a suggestion to clone the entire gramps & addons-source repositories in the gramps-project GitHub space.

But when I see those clones in public repository of different GitHub users, the only “ZIP Download” is for the ENTIRE repository. Drilling down to a folder of a plugin (built-in or add-on) that they tweaked does not offer to ZIP just that folder. So ZIPInstall would do ugly things to my plugins installation.

So, in my GitHub space, I’m doing a repository for the connected add-ons that I’m hacking. Just because that will offer a usable GitHub ZIP generator.

What am I missing?

[emyoulation]

Perhaps an emergency process could be started to get at least a trickle flowing through the pipeline again.

Besides the new Add-ons that @DavidMStraub notes are lanquishing for his project, there are some patches to add-ons that limit beta testing of other add-ons to ‘technically adept’ users. (Like the Error to Console · Issue #221 · cdhorn/CardView · GitHub causing problems for @cdhorn with @prculley 's RestoreHist addon.)

[emyoulation]

Just reviewed some old developer mail.

Has the project seen a decline in thoughput? There’ve been some very nice updates to the software in the last couple years and a surge of impressive plug-ins and external tools.

Looking at the activity of the list of the Gramps repository GitHub Contributors, have we dropped below the volume of active senior developers needed to keep things moving? Too many of the contributors shown on the main page haven’t logged a commit to Gramps in years.

Maybe the process is getting in way of progress. If the process is too onerous, we lose volunteers.

Re: [Gramps-devel] Pull request policy

From: Nick Hall <ni…@gr…> - 2018-06-30 20:54:56
On 30/06/18 14:52, Paul Franklin wrote:

I repeat again:

Should we require pull requests for significant changes?

There have already been some posts about this in the governance thread and opinions seem to be divided.

After considering the feedback, I suggest we keep both approaches for now. Direct merging will still be acceptable for minor changes. Since this only applies to senior developers, I will leave the definition of “minor” up to the individual developer.

Paul,

We eventually decided that pull requests are required except for trivial changes. As a rule of thumb, if a change is modifies more than one file or more than a few lines of code you should submit a pull request.

So just to make things really clear:

1. Your proposed change is not regarded as trivial.
2. Your proposed change requires a pull request.

Regards,
Nick.

Perhaps some of the active People here could be promoted to senior status?

Could actively inviting people; like @DavidMStraub, @Mattkmmr, @kku @cdhorn, @GaryGriffin, @codefarmer, ( or other key project members like @bmatherly ) to be more visible as senior contributors; be something that helps reinvigorate the process?

Having a few others with less Gramps code experience but extra enthusiasm doing triage may be necessary. (I’m not suggesting that for me! I lack the code skills to even read Python properly.) Perhaps these brave souls would even be given ability to re-categorize some PRs as’ trivial changes’ during triage. That kind of power will surely create some problems but that’s the nature of change. People will grow into it.