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

Kent James kent at
Fri Dec 26 20:14:09 UTC 2014

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list