Coder Social home page Coder Social logo

addon-datastore's People

Contributors

cary-rowen avatar cyrilleb79 avatar feerrenrut avatar github-actions[bot] avatar ibrahim-s avatar jmdaweb avatar josephsl avatar jscholes avatar leonardder avatar michaeldcurran avatar nvdaes avatar samkacer avatar seanbudd avatar tspivey avatar xltechie avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

nvdaes josephsl cyrilleb79 nvda-es nsoiffer ruifontes ibrahim-s tspivey samkacer nvaccess leonardder lukaszgo1 jscholes

addon-datastore's Issues

Ensure add-on release origin is authentic

PR #35 demonstrates a potential issue with automatic approval of PRs. Data in a prior submission can be changed, pass verification, and potentially auto-merged. In this case the author and license are changed. It would also be possible to change the download URL and SHA.

Some ways to address this:

  • An add-on release is expected to be immutable, once submitted, users may have it installed. To fix an issue, a new version should be released.
  • Don't allow file deletion without manual approval (requiring explanation).
  • Introduce a way for authors to digitally sign add-on releases, so their origin can be confirmed.

Migrating add-ons: duplicate entries due to legacy versus actual ad-don ID's

Hi,

Follow-up of #89

There are add-ons that will have duplicate entries, more so if they use legacy add-on ID's. For example, Resource Monitor (add-on ID to use: resourceMonitor) is also listed under the ID of "rm". I myself will use the add-on name field from manifest as add-on ID and plan to submit Resource Monitor 23.04 under "resourceMonitor" ID.

The short names (legacy add-on files repo) were chosen to keep the add-on keys short to help translators translate add-on docs on community add-ons website easily (probably due to Ikiwiki limitations).

Thanks.

Allow 'dev' version of add-on

The add-on datastore system currently has:

  • stable - Add-ons that are considered release quality for a released version of NVDA.
  • beta - Add-ons that are pre-release quality for a released version of NVDA.

There is no category for "pre-release add-on for pre-release NVDA". This category is important to allow "dogfooding" by add-on developers to while developing against alpha. This is particularly important during compatibility breaking releases; NV Access wants to facilitate early feedback from add-on developers when changes are made to the NVDA API available for add-ons, for this there must be a low-friction way for add-on developers (and a dev audience) to test out the changes.

Adding a dev version could, allowing submissions for Add-on API versions yet to be released (read: relaxing the Add-on API compatibility constraints imposed by the addon-datastore-validation repo when the submission is in the dev channel) could help to alleviate this, giving:

  • stable add-ons - final/release/stable, being developed for an already released version of NVDA.
  • beta add-ons - Pre-release, being developed for an already released version of NVDA (I.E. it has been added to the set of available releases in the addon-datastore-transform repo)
  • dev add-ons - Pre-release, being developed for currently in alpha/beta/rc version of NVDA.

Ensure that definitions in the readme are updated to match.
Currently it says (in the Considerations section):

  • Enable support in the store for 'beta' add-ons, for instance:
  • add-ons being developed against alpha / beta NVDA.
  • add-ons that want early feedback from end users.
  • End users can choose "show me beta add-ons"

It should become:

  • Enable support in the store for 'beta' and 'dev' add-ons, for instance:
  • 'dev' add-ons are being developed against alpha / beta / rc NVDA, these would only be offered to alpha / beta / rc NVDA users.
  • 'beta' add-ons are from authors who want early feedback from end users, signaling that not all edge cases are handled.
  • End users of NVDA can select "show pre-release add-ons"

Discussion: removing legacy add-on ID's

Hi,

The following is considered a near-term goal:

Currently the add-on datastore contains multiple entries for the same add-on due to the migration from old add-on files repository to the datastore. For example, Add-on Updater is listed under both "nvda3208" (old add-on ID) and "addonUpdater" (new and official add-on ID). While we can use download links (repo addresses) to figure out how many add-ons are actually registered, presence of legacy and actual datastore entries can cause miscalculation of actual add-on count for various purposes such as statistics. Therefore, it is proposed to remove legacy add-on ID's from the datastore, subject to notes from authors/publishers to make the add-on count more realistic and to standardize on using add-on name field found in the actual add-on manifest as actual add-on ID.

Specifically:

  1. Survey add-ons community and authors about which add-on ID's should be used as official ID's.
  2. For ID's coming from legacy add-on files repository, ask authors and/or publishers about keeping or removing them.
  3. If authors request removing legacy add-on ID's, the author and/or someone should create a pull request to remove legacy ad-on ID's. The pull request comment must specify the legacy add-on ID being removed and the new (official) add-on ID to be used from then on.
  4. If the author chooses to use a different ID (say, the official add-on ID registered more recently), documentation such as community add-ons website must direct users to the new add-on download links via the official add-on ID.

Requirements:

  • Multiple entries for the same add-on must be present in the add-on datastore.
  • At least one duplicate entry must be a legacy add-on ID from now archived add-on files repository.
  • Add-on author/publisher specifies which add-on ID to be used as official and whether to keep the legacy ID's or not, along with actions to be taken such as updating documentation.
  • One pull request per add-on, including unifying multiple add-on ID's for the same add-on into one.

Ideal timeline and process:

  • Now: add-on author/publisher identifies add-ons with multiple datastore entries, including entries coming from add-on files repository and marked as legacy. Data should be added as a comment on this issue.
  • At least a week after NVDA 2023.1 stable version is released: start working on pull requests to remove legacy add-on ID's if authors/publishers specify it.
  • Very close to publication of release candidate for NVDA release with add-on store included: complete legacy add-on ID removal process.

Thanks.

Document the process for add-ons currently available on the website

This may be especially important since:

  1. Many of these add-ons have been tested and used for a long time.
  2. Since the review process for this store is not documented yet, some of them may not fit the future proposed criteria.
  3. The development section of the website may contain add-ons not currently maintained.

Proposal:

  1. Add a note about including/excluding of add-on store add-ons currently available from the website, considering that it maybe considered as the equivalent to the future store (since it's mentioned on the NVDA's user guide and it's accessible from a dedicated button in the add-ons manager).
  2. Provide enough time to authors/reviewers to fit the proposed criteria before excluding add-ons currently availab.e

Use GitHub actions to check the SHAs and validity of URLs

What happens if an URL is not available anymore? E.g. deleting a GitHub release by mistake.

From the add-on author point of view, I guess that this version should be revoked and a new should be made. But what if the author do not revoke it? May an add-on be revoked due to a permanently broken link (or a modified SHA)?

Originally posted by @CyrilleB79 in #109 (comment)

A GitHub action should check the SHAs and ensure the URLs work for all versions of add-ons hosted in the add-on store.

Document the process for translators

Regardless of the documentation for a multilingual store, add-ons are translatable and this should be documented ASAP to avoid deletions or regressions, given that they are in fact translated, using the system created by @mhameed:

  • Documentation, gettext messages and translatable mainfest keys could be sent to the system when a PR is approved or merged.
  • Translated messages can be included in the add-on source code and binary and the corresponding commit could be automatically added to the submission repo, deleting the commit against it was created. This shouldn't require to be reviewed and maybe automatically posted on the store, if translations are sent periodically in a programed way as done now with automatic.crontab.

Fix translations system for add-ons

I tried to create an issue in mrConfig without success (not sure if they are disabled).
Many notifications are sent from Exbi server about mr commands not working. This should be fixed if possible.
Alternatively, it maybe announced that add-on maintainers should take care about translations (and or also regarding other questions) independently without depending on a central system.
BTW: This is done ia a project about which I was informed recently, where each person can publish plugins in pip repository without requiring to pass a review process, and the program has an option to install a plugin manager. Alternatively plugins can be installed from command line via pip, but the fact is that they can be included in the program directly without a central system. I think that two approaches are valid, and maybe good for developers to know what they should do:

https://github.com/openstenoproject/plover/wiki/Plugins

What community could do to help?

I believe making this proposal a reality would be a great milestone for NVDA biggest advantage being native updates for add-ons, transparent reviews, and hopefully easier additions to the translation system. It is also worth pointing out that at the moment new add-ons are not being added to the translation and in general current reviewers are waiting for NV Access to implement this before submitting new add-ons to the website. It would be great if you could provide any ETA for this @feerrenrut I understand that it might not be a priority for you therefore I would like to ask what we as a community could do to make this happen in a reasonable time frame - I am thinking rather in a technical terms, as the proposal seems to be discussed enough times and ironing any rough edges might be done when implementing.

Add-on submission and other doc clarification

Issue

Since yesterday, this add-on store repo is the repo where add-on submission should be asked, in replacement of old addonFiles repo.
However, there are still unclear points on how to submit a new add-on or an add-on update.

Solution

Documentation separation

Today, all the documentation is in the main readme. The audience of this readme is for add-on authors, add-on submitters and add-on store developers. It contains:

  • A list of requirements for the add-on store
  • Design information of the add-on store
  • Instructions on how to submit add-ons

I think that this readme should be split in various documents. More specifically from an add-on author point of view, the instructions on how to submit an add-on should not be mixed in the same document with add-on store requirements or design considerations. The repo's main readme could contain just a little intro and 3 linnks to these documents so that each audience only looks at the appropriate information.

The document targetting add-on authors and submitters (in case the submitter is not the author) should contain:

  • the instructions on how to submit an add-on
  • additional requirements (if any) for an add-on to be submittable to the store if requirements are not the same as the ones required to be installable in NVDA

Documentation update

The following points should be updated/clarified:

Use valid examples

Example is given for the NV Access add-on, 'NVDA - OCR':
If we are talking of NV Access (initial) version of this add-on it is not updated since 2020. And the version present in the migration of the store is the one forked and continued by Łukasz Golonka. So better use an example already present in the store rather than an add-on name that will probably never be in the store (addonId "ocr" instead "nvda-ocr")

Version in json

Regarding the json file it is written:

<version> is the add-on version in the form: Major.Minor.Patch E.G. "2.4.1"
Is it a requirement? If yes, it is an additional information that needs to be provided since the "version" field in the manifest rather seems to match "addonVersionName" in the json.

Versioning scheme

Clarify these points:

  • Are there recommendations or additional requirements regarding versioning scheme, especially for dev and beta version.
  • The legacy add-ons present in the repo use x.y.1 for dev versions. Is it a requirement, a recommendation or only something that has been done when migrating the add-ons but that does not require to be continued?

Auto-check:

Automated checks for common issues will complete. Either giving feedback or merging the PR.

As I understand this sentence, automated check completion can trigger automatic merge; even if not explicitely written, that's what the sentence seems to mean.
If I am not mistaken, automatic merging is only a project but not yet enabled. Current sitatuation should be documented, even if future project can also remain mentioned.

Json fields description

Some fields in the json are the same as the ones in the manifest (even if renamed); other ones are new.
A description of each field should be done, giving the correspondance (if any) in the manifest file in case the field name differ between json and manifest.

License URL is optional in issues but not in the GitHub .yml file

I think that two things should be addressed:

  • If an issue field includes "No response", set this field to ''
    • Create an extra step in the GitHub.yml file sot that, if license URL is set to '', the run command doesn't include this argument.
      As aside, reading the NVDA license, seems that add-ons can just be released under GPL2, except for third party components, so I'm not sure if other compatible licenses can really be used. If not, license URL may not be optional for simplicity, since it's know. Or this may require to change something in the license file of NVDA. Really I don't know about licenses.
      cc: @DraganRatkovich

Migrating add-ons: some add-on ID's will have duplicate entries differing by case

Hi,

While migrating my add-ons to the add-on store, I'm noticing that there are add-ons that will have add-on ID/folder name conflicts (I use add-on name field from the manifest as add-on ID). Examples include evttracker versus evtTracker (the latter is the add-on ID I plan to use), officedesk versus officeDesk, and possibly others. As much as I would like to use the add-on name from the manifest (camel case names) as add-on ID, if lowercase names are to be used, I'll abide by it. Note that the two examples I listed are add-ons I'm no longer maintaining.

Thanks.

Some add-ons are added to views branch in the next submission

Problem

Finally, add-ons are copied to the views branch as required, but sometimes this is done when another add-on is sent

Posible suggestion

transformDataToViews.yml workflow maybe run on schedule for example every hour instead of running it when PRs are marged?
Cheers.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.