[Maildev] Integrating popular and useful extensions into TB

Jonathan Kamens jik at kamens.us
Sat Dec 9 16:36:20 EST 2017


On 12/9/17 9:53 AM, ace wrote:
> 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
> subdir.
> 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?

You are not going to convince me that maintaining code in the
Thunderbird tree will be easier for me than maintaining a separate
add-on, so please don't waste your time or mine trying.

I am not saying that there aren't advantages to the code being in the
tree. I'm saying that I, and I'd venture to say most other add-on
maintainers as well, will find it much more inconvenient to maintain
code in the tree, and you will scare off some add-on maintainers if you
impose this as a requirement.

None of the reasons why we originally chose to maintain our code as
add-ons rather than as part of Thunderbird have changed. At most, some
of the difficulties with maintaining code in the Thunderbird code base
have gotten incrementally better, but the change has not been dramatic.

If you want the add-ons to continue to be available, and you want add-on
maintainers to continue maintaining them rather than the Thunderbird
development team taking over maintenance of the code, then you're going
to have to find a way to work with the add-on maintainers on their terms
rather than imposing a solution on them that they won't like.

> 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.

You can impose minimum requirements on add-on maintainers who want help
from the Thunderbird development team. E.g., their code needs to be
available in a public repository that does pull requests, it needs to be
easy for a developer to run their add-on from source code (e.g., the
directory layout of the source code for all of my add-ons is structured
to allow them to be run directly from the source tree), etc.

  jik


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/attachments/20171209/2632b2d8/attachment-0001.html>


More information about the Maildev mailing list