On 07/12/2017 15:11, Jonathan Kamens wrote:

+1

To my knowledge, we Thunderbird developers assist add-on authors to the
best of our abilities and possibilities of the code base.

Jörg.

On 07-Dec-17 8:50 AM, Ben Bucksch wrote:

This is an interesting list,  it also begs a couple of slightly off
topic observations.

1. Extra folder columns has been integrated since V38.  So no one should
   have it installed and active if they are keeping up with the version
   releases.  So I think we need to ask about it's presence in the list. 
   Is it telling us about people not updating, flaws in the data collection
   that made the list Or a failure of blacklisting.  This add-on should
   have been blacklisted in V38.

2. Compact header integration has been discussed since  7 years ago in
   Bug 634831.  The interest was there way back.  Folk with an interest in
   completing the original vision of tabs were also suggesting that was a
   better solution.

.Matt

----- Pôvodná správa -----
Predmet: Re: [Maildev] Integrating popular and useful extensions into TB
Od: Matt Harris unicorn.consulting@gmail.com
Pre: maildev@lists.thunderbird.net
Dátum: Sat, 9 Dec 2017 08:11:07 +1030

There are multiple options how to do this (if it is ever wanted) so they
need to be investigated and decide upon:

1. keep them as extensions just bundle it with TB (as Lightning). But
   would this solve the problems they are facing? Yes, we would update them
   when some interface changes hit whole c-c. But the interfaces to enable
   them being extensions are still there and those are killed by m-c gradually.
2. will we integrate their code by copying them unter
   /mailnews/extensions ? They will still stay as a logical group of files
   comprising the feature.
3. will we integrate their code sprinkling it at all the places where it
   belongs throughout the c-c tree? This would totally loose the "identity"
   of the extension.

The question then is whether the extension authors do this, and the keep
maintaining the code inside the c-c tree.

Yes, good question. The addon code was integrated and the addon is
marked compatible only up to TB 37 on AMO. We should try to understand
why there are users with it active.

aceman

----- Pôvodná správa -----
Predmet: Re: [Maildev] Integrating popular and useful extensions into TB
Od: Jonathan Kamens jik@kamens.us
Pre: Thunderbird email developers maildev@lists.thunderbird.net, Ben
Bucksch ben.bucksch@beonex.com, TB Council
thunderbird-council@mozilla.org
Dátum: Thu, 7 Dec 2017 09:11:23 -0500

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?

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.

On 12/7/17 2:06 PM, Ben Bucksch wrote:

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, with clear instructions, and wherever possible sample code,
explaining how add-on maintainers can fix their code to recover from
each breaking change while maintaining backward compatibility with
earlier Thunderbird releases extending back a reasonable amount of time
(e.g., I don't know that add-ons still need to support Thunderbird 3,
but it's not unreasonable to want to continue to support Thunderbird 30).

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.

In the case of a particularly complicated breaking change which is going
to require a lot of work to recover from -- e.g., we're eventually all
going to have to convert our overlay add-ons to bootstrapped add-ons,
right? -- I think it would lovely if Thunderbird developers would
volunteer to help add-on maintainers with the actual coding effort
necessary to recover from the change.

I will happily accept PRs on Github for all of my add-ons! ;-)

FYI, I wrote and maintain:

• https://github.com/jikamens/send-later (way back in Thunderbird 2
  days it was written by someone else, but by this point I've
  rewritten pretty much the whole thing)
• https://github.com/jikamens/remote-content-by-folder
• https://github.com/jikamens/reply-to-multiple-messages
• https://github.com/jikamens/ShowAllBodyParts (a ridiculously trivial
  add-on which just sets mailnews.display.show_all_body_parts_menu to
  true)
• https://github.com/jikamens/folder-pane-view-switcher
• https://github.com/jikamens/enhanced-priority-display
• https://github.com/jikamens/undigestify
• https://addons.mozilla.org/thunderbird/addon/imap-received-date/ (I
  haven't gotten around to moving this one from my private repository
  into Github yet; in any case, it's a ridiculously trivial add-on
  which just adds "Received" to mailnews.customDBHeaders)

I've taken over maintainence of orphaned add-ons:

• https://github.com/jikamens/ToggleReplied

I also help with maintaining:

• https://github.com/trlkly/dorando-keyconfig

jik

On 12/9/17 9:53 AM, ace wrote:

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.

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

On 2017-12-09 6:41 AM, ace wrote:

Extra folder columns currently only has 5,616 users on AMO. Ben's list
is based on a spreadsheet from July and use of this add-on completely
died in June around the 20th (see:
https://addons.mozilla.org/en-US/thunderbird/addon/extra-folder-columns/statistics/?last=365).

I have no idea why this is, it doesn't coincide with a major release or
anything. By that time, we had already been on 52 for months, let alone 38.

On 11-Dec-17 7:34 PM, Andrei Hajdukewycz wrote:

No access to statistics here,  But I do not doubt that it may have
recently died.  It has also recently started appearing in comments in
support.  Nothing definitive, but it might finally be causing problems

Matt