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. > 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. > I would like there to be a mailing list that add-on maintainers can > subscribe to whose one and only purpose is to announce each breaking > change as it is discovered and point add-on maintainers at the > instructions on the aforementioned web site for how to deal with that > particular breaking change. > Good idea. You might be able to subscribe to the wiki page, though.

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. >> 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. 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. 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. 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. >> I would like there to be a mailing list that add-on maintainers can >> subscribe to whose one and only purpose is to announce each breaking >> change as it is discovered and point add-on maintainers at the >> instructions on the aforementioned web site for how to deal with that >> particular breaking change. > Good idea. You might be able to subscribe to the wiki page, though. Sure, if the wiki page actually existed and had the content on it that I'm asking for, I could do that.   jik

----- Pôvodná správa ----- Predmet: Re: [Maildev] Integrating popular and useful extensions into TB Od: Jonathan Kamens <jik@kamens.us> Pre: Ben Bucksch <ben.bucksch@beonex.com>, Thunderbird email developers <maildev@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 available?

ace wrote on 10.12.17 02:03: > Why should we create a page about changes we didn't make and are also > hit by them? Because our addon authors need it. > 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. Firefox 57 and later doesn't have XUL addons anymore, so I don't think they will continue to maintain a page of API changes for things that no longer exist. It does exist for us, so we need to maintain it now. Ben