Publish to Thunderbird Addon Directory

[smehrbrodt]

Please do :)

Here are some instructions how to submit addons: https://developer.mozilla.org/en-US/Add-ons/Distribution

Original issue: Ericsson#480

[BenjamenMeyer]

yes, it would make staying up-to-date a lot easier

[retorquere]

Getting on the addons distribution site also means you're subject to Mozilla code reviews; Zotero (and my extension to Zotero) went through the process and bailed, as the delay for even critical fixes was unacceptably long. The upside is that hosting it on AMO automates the process of updating; it's possible to do auto-update without hosting the extension on AMO, but it takes a little work to set it up.

[Trim]

Hello,

Indeed it would be good to have the addon on AMO, but we'll certainly fail at Mozilla code reviews as the extension code is really old, and overwrites a lot of things.

Furthermore, currently, we are using an extension identifier which is already on AMO: so we'll have to replace it with our version. I'm not sure Mozilla will let us do that ;)

[retorquere]

You can just host it as a new extension, but non-AMO auto updates are pretty easy, and the delays from review are not funny when you're clamoring to put out a critical patch. The zotero team has some interesting horror stories on that one.

[jamesquilty]

Another benefit of publishing to AMO is that it draws this extension and its usage statistics to the attention of the people most active in the community, including the council, developers and reviewers. There have been several recent posts to the tb-planning mailing list discussing extension update and usage statistics, the most recent of which includes a request to relay an offer of help with updating extensions.

It would be wise to take advantage of that offer at a time when Thunderbird is going through some significant changes.

[jamesquilty]

@advancingu @Trim I see that a lot of effort is being put into the 5.0.0 beta, which is much appreciated. I might be able to work on this Issue, if it would help. Please assign this Issue to me if you'd like me to try to have the extension published on AMO.

[Trim]

On my side, I've began a new job last spring and I don't have any more any Exchange account.
So, as I don't use ExchangeCalendar daily, I've lost motivation to work on this extension, sorry ;-)

So, I think that would be cool if @jamesquilty can take the task to publish on AMO. Note that, this extension has a lot of code and it certainly doesn't fulfill code quality requirements to publish on AMO. Although, that would be a very good improvement to be able to publish directly there !

[jamesquilty]

@Trim Thanks for the reply, and sorry to lose you from the project.

@advancingu I'd like to help. A quick test indicates two errors preventing submission to ATN:

1. Duplicate add-on ID.
2. Invalid maximum version number 60.*.*.

Advice from the TB-Planning list on the first error is that the extension authors should change the add-on identifier. That's simple, I believe.

The second error is near-trivial to fix: the valid version number should be 60.* according to the Thunderbird Valid Application Versions page.

Obviously, I don't have role permissions to do either of these directly on this project but I guess we could do the "fork, fix and pull [request]" dance?

[ovari]

@advancingu @Trim, so that a fork is not required, can the following people please be added as members to this repository:
@jamesquilty
@cleidigh

What do you think?

Thank you

[jamesquilty]

@advancingu @Trim I'm afraid I have a fairly short window available to advance this Issue. Would it be possible to add me as member of ExchangeCalendar?

[jamesquilty]

@advancingu I've raised Pull Request #292 for modifications allowed the 5.0.0-beta1.xpi to pass the automated validation tests without errors, per your advice in #277. The Validation Results for exchangecalendar-v5.0.0-beta1.xpi are probably only visible to me via my ATN account, but the brief version is as follows:

General Tests
0 errors, 0 warnings, 27 notices
    No <em:type> element found in install.rdf
    Linked manifest could not be found (x26)

Security Tests
0 errors, 1 warning, 0 notices
    Overlay contains generically-named IDs

Extension Tests
0 errors, 41 warnings, 0 notices
    Access to the `executeStep` global (x16)
    `open` called in potentially dangerous manner
    Access to the `getInstallForURL` global
    on* attribute being set using setAttribute (x10)
    Mouse events may cause performance issues (x2)
    `setTimeout` called in potentially dangerous manner (x2)
    SQL statements should be static strings (x8)
    Variable element type being created

Localisation Tests
0 errors, 0 warnings, 0 notices
All tests passed successfully.

Compatibility Tests
0 errors, 0 warnings, 0 notices
All tests passed successfully.

[jamesquilty]

An unexpected consequence of my testing is that the add-on ID [email protected] "will continue to be linked to your account, so others won't be able to submit versions using the same ID." I don't intend to become the add-on publisher/author on ATN there are a couple of ways of addressing this. It does raise the question of which account should be used to publish the add-on?

A shared/organisational ExchangeCalendar account on ATN would seem to be the appropriate answer, as github.com/ExchangeCalendar is an Organisation for the "ExchangeCalendar community" (per the statements in install.rdf and README.md).

@advancingu My unilaterally creating an ExchangeCalendar account on ATN with an associated shared email address (e.g. an address [email protected]) would not be a community-minded move on my part, so I'd like to ask your thoughts on the matter?

[advancingu]

Fyi, I've just submitted the add-on for review using an account in my name. If I ever leave the project, I will hand over to a future maintainer.

[jamesquilty]

@advancingu has there been any response from ATN to the submission for review, please?

[advancingu]

@jamesquilty Unfortunately I don't see that there has been any activity.

[advancingu]

So today I finally received review feedback. The extension was rejected and the following changes were requested:

1. Can you consider using mouseenter/mouseleave instead of mouseover/mouseout at calendar/content/calendar-summary-dialog.js line 536 ?
2. In calendar/content/ecCalendarCreation.js and a few other files you are setting on* attributes on Lightning's elements, please move this to use addEventListener instead. Otherwise, other extensions will run into troubles if multiple such provider add-ons are installed.
3. Please remove any sync http requests, e.g. calendar/interface/exchangeTimeZones/mivExchangeTimeZones.js line 434
4. Similarly, please use async SQLite statements, e.g. common/content/offlineCacheSettings.js line 148
5. In common/interface/updater/mivUpdater.js line 1 it looks like you have a custom updater. In moving this to ATN, please remove the custom updater and use ATN updates instead.