Massive addon update project
Bug 1391020 "Quicktext No Longer Displays after Upgrade to Version
56.0b2 (32-bit)" is a reminder that there will be a massive effort to
update addons for TB 59. Many of our important addons are barely or
not-at-all maintained. I ended up with Quicktext only because it was a
commonly used addon that had been abandoned that needed trivial changes
to keep running. There are many others in a similar state for TB 59.
Earlier I asked in tb-planning if anybody would take on the project to
document the changes needed for addons between TB 52 and TB 59, but got
no takers. I also think we should seriously consider removing compatible
by default for TB 59, as without update very few addons will work in TB 59.
The changes to update addons are likely to be common over many addons,
so it might be helpful to have this work done by a single person for
many addons. I wonder if this makes sense for us to recommend, that TB
consider hiring a developer to do a one-time update of many XUL addons
to have compatibility with TB 59. Might anybody be interested in such a
contract, if the Thunderbird Council approved it?
Kent James
R Kent James via Maildev wrote on 17.08.2017 00:36:
The changes to update addons are likely to be common over many addons,
so it might be helpful to have this work done by a single person for
many addons
Agreed.
That person would then also easily identify and find ways to automate or
script the changes.
(No comment on hiring, as I think we should try to get volunteers
involved. Might be a good way for people to get started?)
On 17/08/2017 02:12, Ben Bucksch via Maildev wrote:
The changes to update addons are likely to be common over many addons, so it might be helpful to have this work done by a single person for many addons
Agreed.
That person would then also easily identify and find ways to automate or script the changes.
I don't understand the logistics of this at all.
Add-ons have an author who is responsible for updating and uploading his/her add-on. Some of the add-ons I use stopped working on recent Dailies, so I advised the authors of how they needed to fix their code. And they did and uploaded new versions to AMO.
I understand that we have somehow adopted QuickText, but then when we have a beta user that complains, it's none of our priorities which is not a position a responsible add-on author should take.
I am strictly opposed to adopting any more add-ons. Sure, we can inspect their code and suggest fixes to the authors, but we should not ever assume responsibility.
If anyone still feels the urge to adopt an add-on, please adopt the Dropbox filelink add-on that will stop working at the end of September 2017 since Dropbox will drop version 1 of their API.
Jörg.
Jörg Knobloch via Maildev wrote on 17.08.2017 02:31:
On 17/08/2017 02:12, Ben Bucksch via Maildev wrote:
The changes to update addons are likely to be common over many
addons, so it might be helpful to have this work done by a single
person for many addons
Agreed.
That person would then also easily identify and find ways to automate
or script the changes.
I don't understand the logistics of this at all.
Add-ons have an author who is responsible for updating and uploading
his/her add-on. Some of the add-ons I use stopped working on recent
Dailies, so I advised the authors of how they needed to fix their
code. And they did and uploaded new versions to AMO.
I understand that we have somehow adopted QuickText, but then when we
have a beta user that complains, it's none of our priorities which is
not a position a responsible add-on author should take.
I am strictly opposed to adopting any more add-ons. Sure, we can
inspect their code and suggest fixes to the authors, but we should not
ever assume responsibility.
This is not a question of who is responsible, but of value for our end
users. If many addons break, our users have a problem. These are our
users, too.
The suggestion is not the adopt addons, but to fix certain breakages
where common APIs changed and break many addons.
It is much more efficient to make the same change in 50 addons, than
requiring all addons authors to fix it individually.
Also, more importantly, many addons don't have a maintainer anymore, but
apparently are still working. Many of these would break. Not good for users.
We're not suggesting that we (as in you, personally) do that, but that a
volunteer does it, or an outside contractor. This is a good way to train
somebody in Mozilla tech, actually, before we let him hack the core.
He'll be exposed to lots of XPCOM code (often bad code, admittedly), and
get to know many Mozilla APIs.
Ben
I agree compatible by default should definitely be removed.
Offering to update 3rd party add-ons seems like a dangerous precedent. We
really need a higher people/code ratio, and shouldn't adapt more code for
Thunderbird core to carry.
We also often forget add-ons are niche if you see to the general population,
with only around 10 add-ons that are are popular enough to have > 1% of user
share. If one of the top 10 add-ons isn't updated, maybe we can consider
helping out, but for all the smaller ones I would require them to carry their
own weight.
-Magnus
On 17.8.2017 01:36, R Kent James via Maildev wrote:
Bug 1391020 "Quicktext No Longer Displays after Upgrade to Version 56.0b2
(32-bit)" is a reminder that there will be a massive effort to update addons
for TB 59. Many of our important addons are barely or not-at-all maintained.
I ended up with Quicktext only because it was a commonly used addon that had
been abandoned that needed trivial changes to keep running. There are many
others in a similar state for TB 59.
Earlier I asked in tb-planning if anybody would take on the project to
document the changes needed for addons between TB 52 and TB 59, but got no
takers. I also think we should seriously consider removing compatible by
default for TB 59, as without update very few addons will work in TB 59.
The changes to update addons are likely to be common over many addons, so it
might be helpful to have this work done by a single person for many addons.
I wonder if this makes sense for us to recommend, that TB consider hiring a
developer to do a one-time update of many XUL addons to have compatibility
with TB 59. Might anybody be interested in such a contract, if the
Thunderbird Council approved it?
Kent James
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 18/08/2017 09:19, Magnus Melin via Maildev wrote:
We also often forget add-ons are niche if you see to the general
population, with only around 10 add-ons that are are popular enough to
have > 1% of user share. If one of the top 10 add-ons isn't updated,
maybe we can consider helping out, but for all the smaller ones I
would require them to carry their own weight.
Helping out - as I've been doing for the add-ons I care about by
advising the authors - 100% agreed.
Taking over the add-on: No.
Jörg.
On 18/08/2017 00:27, Ben Bucksch via Maildev wrote:
The suggestion is not the adopt addons, but to fix certain breakages
where common APIs changed and break many addons.
Sorry, but you haven't explained the logistics of this. So we take an
add-on we know broke and fix it. Now what? Beg the owner to take those
changes and publish a new version? Forcefully hijack his AMO or future
TB-AMO account and do it for him/her?
It is much more efficient to make the same change in 50 addons, than
requiring all addons authors to fix it individually.
Agreed.
Also, more importantly, many addons don't have a maintainer anymore,
but apparently are still working. Many of these would break. Not good
for users.
Agreed, but please explain the logistics. For the add-ons that don't
have a maintainer, what do you do? Take it over, right? Like QuickText?
And then do a bad job for beta users? Not good for users.
We're not suggesting that we (as in you, personally) do that, but that
a volunteer does it, or an outside contractor. This is a good way to
train somebody in Mozilla tech, actually, before we let him hack the
core. He'll be exposed to lots of XPCOM code (often bad code,
admittedly), and get to know many Mozilla APIs.
Great idea, but please explain the logistics first. I won't repeat what
I said above.
Jörg.