Change of release and governance model for Thunderbird

Kai Engert kaie at kuix.de
Mon Jul 9 16:57:35 UTC 2012


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.

or

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

Regards
Kai




More information about the tb-planning mailing list