On Mon, Jul 9, 2012 at 9:57 AM, Kai Engert <span dir="ltr"><<a href="mailto:kaie@kuix.de" target="_blank">kaie@kuix.de</a>></span> wrote:<font face="tahoma,sans-serif"><br></font><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The one thing I'm worried about is regressions.<br>
<br>
Firefox and Thunderbird share application level code that is responsible<br>
for the correct functioning of security protocols.<br>
<br>
If a change is made because it's needed by Firefox, it's easy to forget<br>
that Thunderbird may rely on the previous behaviour, and the change<br>
might cause a regression in<br>
functionality/usability/correctness/completeness for Thunderbird.<br>
<br>
This has happened in the past. If Thunderbird becomes even less of a<br>
priority for the Mozilla project, with even fewer people available to<br>
work on cleanup and adjustments to newer Gecko core, then there's the<br>
risk that such regressions might occurr more frequently in the future<br>
<br>
I have a very clear opinion how this should be handled. In my opinion,<br>
existing functionality in the core engine should never be removed, if<br>
it's currently being used by important projects such as Thunderbird.<br>
Instead of removing functionality from the core engine, because it<br>
allowed Firefox projects to proceed faster (happened in the past),<br>
developer should take care to implement additional features in addition,<br>
not as a replacement.<br>
<br>
Unfortunately I failed in convincing people to use this strategy, and it<br>
had been decided that Firefox is more important, and that the<br>
Thunderbird project has to adopt. With fewer resources devoted to<br>
Thunderbird such adoption will become less likely to happen.<br>
<br>
I'm worried there are only two approaches to this dilemma.<br>
<br>
(a) Tell developers to do what I suggested above - keep core<br>
functionality - implement new core functionality in addition. This<br>
strategy would be very helpful to allow Thunderbird with the most recent<br>
(and most secure) Mozilla platform code.<br>
<br>
or<br>
<br>
(b) In order to avoid being broken, accept that Thunderbird might have<br>
to fork portions of the Gecko code, in order to remain compatible. But<br>
as soon as we go that path, we might soon see Thunderbird having to use<br>
a full fork of Gecko and fall behind. I don't think we'd be happy with<br>
this scenario.<br>
<br>
<br>
I therefore propose that we make it a rule that developers must follow<br>
strategy (a). If developers want to remove or replace a functionality in<br>
core Gecko, they must not do it until someone has contributed a working<br>
adjustment to Thunderbird code.<br>
<br>
Regards<br>
Kai<br><br></blockquote><div><br></div><div>I think the plan is to base the Gecko version on the ESR version of Thunderbird.  That means they will not be changing the Gecko version unless they release a new ESR, which if I am not mistaken only happens about once a year.  While the Firefox developers might change Gecko and harm Thunderbird, that should be caught in comm-central which has roughly a year to fix until the next ESR release.  I am sure that if comm-central breaks, somebody will probably fix it rather quickly.</div>
<div><br></div><div>Jeff</div></div><br>