<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
(This post is followup #2 to comments in bug <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=441414"><b>441414</b></a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">Treerows need a way to hold
richer content)</span></span><br>
<br>
(In reply to Marcel from comment #201)<br>
> Thunderbird is not maintained officially.<br>
<br>
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").<br>
<br>
(In reply to Ryan Yagatich from comment #202)<br>
> <br>
> ... developers have been seemingly forbidden to code with XUL<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
:rkent<br>
<br>
</body>
</html>