[Maildev] Integrating popular and useful extensions into TB

ace acelists at atlas.sk
Sat Dec 9 20:03:35 EST 2017

----- Pôvodná správa -----
Predmet: Re: [Maildev] Integrating popular and useful extensions into TB
Od: Jonathan Kamens <jik at kamens.us>
Pre: Ben Bucksch <ben.bucksch at beonex.com>, Thunderbird email developers
<maildev at lists.thunderbird.net>
Dátum: Sat, 9 Dec 2017 18:10:42 -0500

> On 12/9/17 5:14 PM, Ben Bucksch wrote:
>> Jonathan Kamens wrote on 09.12.17 22:27:
>>> On 12/7/17 2:06 PM, Ben Bucksch wrote:
>>>> What concrete help would you appreciate most from the TB project?
>>> I would like there to be a comprehensive, accurate, maintained web
>>> site documenting the breaking changes in each release of Thunderbird,
>>> all in one place
>> I think we have such a page, I saw one recently. Fairly rough, but
>> looks actively maintained. I don't have the URL handy, but Jörg can
>> post it.
> It has been discussed here. It has been discussed on other mailing
> lists. I've seen some of these discussions; you probably have as well.
> You may be confusing a list somebody posted in one of those discussions
> with a Wiki page.
> Searching for "Thunderbird add-on breaking changes" in Google does not
> turn up such a page in the first page of results. If it's not on the
> first page of search results, it might as well not exist. And if you
> keep paging through results you can go several pages in and still not
> see find such a page; I eventually gave up. I also tried searching for
> "thunderbird add-on api changes" and "thunderbird extension api changes"
> with similar results. If such a page exists, it is apparently very
> cleverly disguised to make it difficult to find.

Why should we create a page about changes we didn't make and are also
hit by them? For Thunderbird-specific changes, we did announce them e.g.
to mozilla.dev.apps.thunderbird .

So now you learned that you need to search for "Firefox API changes"
too. I even gave you the link directly. Is that the missing piece and
can you continue from here now? Or

>>> with clear instructions, and wherever possible sample code,
>>> explaining how add-on maintainers can fix their code to recover from
>>> each breaking change
>> That we don't have, but any add on author who found one could add it
>> to the page.
> It is INCREDIBLY frustrating when, as an add-on author, I stumble over
> these changes and then I have to stumble around the internet with my
> hands in front of me like a blind man, trying to feel out what has
> changed, why it has changed, and what I need to do to recover from it.

How did you learn how to write an addon in the first place? Is there a
single page with all the APIs and recipes how to do everything? I'd
think you also had to read many docs on the Internet. Why suddenly you
can't read information about changes of the platform you have chosen to
write against? As said, it is available (just titled "Firefox") with
links to relevant bugs with sample code. Many of the bugs are linked to
TB bugs where you see patches we had to do to adapt to those changes.

> This is by far the most unpleasant aspect of maintaining add-ons.
> The people who work with the Thunderbird code base on a regular basis
> are in a MUCH BETTER position to know when things change and what needs
> to be done to recover from the changes.

Yes, unfortunately we know, when they hit us. And you rejected the
proposal that we fix also addons automatically when they are in the
tree. So what exactly do you propose (except duplicating info on the
Firefox dev page) ?

> Once again: don't ask me what I need, and then when I tell you, turn
> around and tell me that I don't actually need that.

And you insist only on your way that we duplicate information that is
already available (in Firefox dev pages and linked bugs).

> If you guys are serious about supporting the Thunderbird add-on
> ecosystem and encouraging people to continue maintaining existing
> add-ons and write new ones, then I strongly recommend a change in
> mindset. Treat add-on maintainers as customers and give them everything
> they need to succeed; don't treat them like peers in the great
> open-source project that is Thunderbird. That's not what they are. They
> are consumers of the Thunderbird add-on framework and API, and most of
> them want nothing to do with helping to maintain the framework, the API,
> or its documentation. They just want to write and maintain add-ons. Stop
> asking or expecting them to do more than that.

Even Firefox devs asked addon authors what APIs they need in
Webextensions (but failed to have them ready for 57).
Some addon authors do cooperate and even send patches to improve TB or
help them with their addon.
We can agree addon authors are customers of sort, but due to their
skills and knowledge, I also expect them to do some work on their part
(not unreasonable, when some even make money from their addon).
They must not expect to be spoon-fed everything like normal users.

So what exactly should we give them (the "everything") that is not yet

More information about the Maildev mailing list