[Maildev] Integrating popular and useful extensions into TB
acelists at atlas.sk
Sat Dec 9 09:53:41 EST 2017
----- Pôvodná správa -----
Predmet: Re: [Maildev] Integrating popular and useful extensions into TB
Od: Jonathan Kamens <jik at kamens.us>
Pre: Thunderbird email developers <maildev at lists.thunderbird.net>, Ben
Bucksch <ben.bucksch at beonex.com>, TB Council
<thunderbird-council at mozilla.org>
Dátum: Thu, 7 Dec 2017 09:11:23 -0500
> I'd like to offer some perspective on this as an author of one of the
> add-ons on the list (Send Later, 11th most popular).
> In my experience, maintaining core Thunderbird code is a huge pain in
> the neck.
> The code base is huge and convoluted, the mixture of different
> the code is crap and unpleasant to work with, the build process --
> although it is getting better -- is cumbersome, it takes a long time to
> build and takes up a huge amount of disk space, incremental builds
> frequently fail due to other people's changes and force a rebuild from
> scratch, writing test cases is unpleasant and complex, when I do take
> the time to make and submit fixes to other people's code in the code
> base my fixes are frequently ignored or I'm told they won't be accepted
> unless I also submit unit tests (as an open-source author of many
> software packages, I never demand that someone submitting fixes to me
> also write test cases; if they go through significant time and effort to
> identity the root cause of a bug and provide a fix, I owe it to them to
> meet them halfway and do the tests if I think they're necessary), it
> frequently takes many months to a fix to make it from being committed to
> being released to the world, making changes to the code base frequently
> requires negotiation, bargaining, and collaboration with people who do
> not always have the time to respond promptly and do not always
> contribute constructively, etc., etc.
If we clearly separated the addon code in the tree (e.g. by putting it
as a subdir in /mailnews/extensions) you wouldn't need to look at the
"crap unpleasant code" in other folders. Problem with requesting tests
or negotiations would be solved if you were marked as the owner of that
Yes, the long time between fixing something and releasing to public is
valid. But if those fixes were made on ESR in point releases, this delay
would be at most 6 weeks. Is that not acceptable?
> But like I said, I don't think you have the manpower and resources to do
> that. If I'm right, then let me suggest an alternative. Rather than
> trying to integrate these add-ons into the Thunderbird code base, offer
> to assist the maintainers of these add-ons by doing the minimal work
> necessary to get each add-on "over the hump" and compatible with
> Thunderbird moving forward, and then, having done that work, let the
> maintainer of the add-on continue to maintain it as an add-on.
Yes, we can do this and have done for several addons. But it is hard for
us to do that when they are out of the tree.
More information about the Maildev