Change of release and governance model for Thunderbird
jeff at stikman.com
Mon Jul 9 17:27:40 UTC 2012
On Mon, Jul 9, 2012 at 9:57 AM, Kai Engert <kaie at kuix.de> wrote:
> The one thing I'm worried about is regressions.
> Firefox and Thunderbird share application level code that is responsible
> for the correct functioning of security protocols.
> If a change is made because it's needed by Firefox, it's easy to forget
> that Thunderbird may rely on the previous behaviour, and the change
> might cause a regression in
> functionality/usability/correctness/completeness for Thunderbird.
> This has happened in the past. If Thunderbird becomes even less of a
> priority for the Mozilla project, with even fewer people available to
> work on cleanup and adjustments to newer Gecko core, then there's the
> risk that such regressions might occurr more frequently in the future
> I have a very clear opinion how this should be handled. In my opinion,
> existing functionality in the core engine should never be removed, if
> it's currently being used by important projects such as Thunderbird.
> Instead of removing functionality from the core engine, because it
> allowed Firefox projects to proceed faster (happened in the past),
> developer should take care to implement additional features in addition,
> not as a replacement.
> Unfortunately I failed in convincing people to use this strategy, and it
> had been decided that Firefox is more important, and that the
> Thunderbird project has to adopt. With fewer resources devoted to
> Thunderbird such adoption will become less likely to happen.
> I'm worried there are only two approaches to this dilemma.
> (a) Tell developers to do what I suggested above - keep core
> functionality - implement new core functionality in addition. This
> strategy would be very helpful to allow Thunderbird with the most recent
> (and most secure) Mozilla platform code.
> (b) In order to avoid being broken, accept that Thunderbird might have
> to fork portions of the Gecko code, in order to remain compatible. But
> as soon as we go that path, we might soon see Thunderbird having to use
> a full fork of Gecko and fall behind. I don't think we'd be happy with
> this scenario.
> I therefore propose that we make it a rule that developers must follow
> strategy (a). If developers want to remove or replace a functionality in
> core Gecko, they must not do it until someone has contributed a working
> adjustment to Thunderbird code.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning