Comments on unmaintained products and technogies (bug 441414 #2)

ace acelists at
Sat Dec 27 23:13:53 UTC 2014

Could we take that patch into comm-central and have it as an extension
to XUL (some override of the tree element)? Maybe we could get somebody
knowledgeable in toolkit (e.g. Neil) to review it and maintain in this way?

I have personally not seen any official announcements or reasons why XUL
would be deprecated already.


-------- Original Message --------
Subject: Comments on unmaintained products and technogies (bug 441414 #2)
From: Kent James <kent at>
To: tb-planning <tb-planning at>
Date: Fri, 26 Dec 2014 12:14:09 -0800

> (This post is followup #2 to comments in bug *441414*
> <> -Treerows need a
> way to hold richer content)
> (In reply to Marcel from comment #201)
>> Thunderbird is not maintained officially.
> In the last official announcement a couple of years ago about the status
> of Thunderbird, Mitchell announced that Mozilla would maintain
> Thunderbird, but not invest in new features. So the idea that
> "Thunderbird is not maintained" does not reflect officially announced
> policy. We are still in the process of transitioning from
> staff-maintained to volunteer-maintained, but Thunderbird is maintained,
> and will be for the foreseeable future if we volunteers have any power
> to effect that (and I do mean "effect" and not "affect").
> (In reply to Ryan Yagatich from comment #202)
>> ... developers have been seemingly forbidden to code with XUL
> In a large project like the Mozilla platform, at any point in time there
> are lots of technologies X where the prevailing viewpoint is something
> like "We would like to replace X Real Soon Now, so we should top
> investing in X" which sometimes gets interpreted as "you are forbidden
> to code in X". Don't exaggerate the importance of these announcements,
> if you do you will find it difficult to do anything in a large project
> like Firefox or Thunderbird, as large portions of the code are affected
> by one or more of these pronouncements. Thunderbird as a whole is under
> one of these pronouncements, and yet many of us labor along investing
> our efforts in the product and disagree with that attitude.
> People sometimes don't appreciate that reviewing code changes can take
> as much or more time than doing the change in the first place,
> particularly when the code is both 1) important and 2) relatively
> obsolete. In the specific case of bug 441414, we had the unfortunate
> confluence of those factors causing difficult reviews, with 3) a
> developer unfamiliar with Mozilla culture, who made excessive demands on
> reviewers, and 4) code that primarily affected Thunderbird, while the
> reviewers were primarily Firefox reviewers. These are not the best
> conditions to make policy, like "we will not improve XUL". When combined
> with a common attitude in Mozilla culture of "once we've decided
> something, we can't change our mind" it can lead to unfortunate results.
> Personally, I interpret that policy to mean "we will not invest lots of
> reviewer time to improve XUL." We have the power to move forward if we
> want to, we just don't have the right to expect excessive review time
> from Firefox developers.
> :rkent

More information about the tb-planning mailing list