WaltS48 wrote:
>Would it be better not to touch that part of the code then ? Would it
>be better to perform regression testing ?
>Or a broken feature is not high priority ? Who knows ?
The Gecko code gets changed by paid Mozilla developers and volunteers
for use in Firefox. If that breaks something in SeaMonkey or Thunderbird...
Yep. Sometimes, new problems aren't introduced by Seamonkey or
Thunderbird developers, but inherited from updates made, as a part of
the Rapid Release cycle for Gecko.
There are times when I wonder if Mozilla is so focused on Firefox, that
the Gecko and Firefox developers don't give adequate consideration to
the effects of changes on derivative and dependent works -- not just
Seamonkey and Thunderbird, but things like Lightning and extensions, and
projects such as PaleMoon, FossaMail, Waterfox, Galeon, Flock, K-meleon,
etc.
With Seamonkey, I find that it happens about once or twice a year, when
a new update breaks something that I use. Most of the time, the effect
is an annoyance, and usually, the problem is resolved on the next
scheduled release.
Yes, there are bugs that are chronic, but for any development project,
there will always be bugs, work has to be prioritized. In the case of
Seamonkey, there's additional dynamics imposed by the fact that it is a
volunteer project, and that the bulk of the work is dependent on what is
done to Gecko, Firefox and Thunderbird. This is the reason that
Seamonkey updates normally lag Firefox updates by about two days. My
understanding is that when there is a Firefox release (whether
scheduled, or out-of-cycle chemspill fix), then it takes a bit of time
to make sure that all the necessary changes are properly applied to the
Seamonkey code.
Smith
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
