Thunderbird Discussions with Mozilla (was Marketing Module)
bkerensa at gmail.com
Thu Jan 8 22:57:10 UTC 2015
One of the reasons I encourage asking for funding is because at the very
least Mozilla through Mitchell did make the suggestion that Mozilla would
continue to provide a team of staff to support Thunderbird but those staff
were also on other teams so did not really have the time to put into the
product that was really promised.
"Mozilla will provide to following resources for Thunderbird:
The Thunderbird release driver team will be composed of the following
- Lead Engineer & Release Driver: Mark Banner
- Back End Integration Engineer: Irving Reid
- Quality Assurance: Ludovic Hirlimann
- Web Development: Andrei 'Sancus' Hajdukewycz
- Support: Roland Tanglao
- Release Engineering: John Hopkins
- Business Development & Legal: Jean-Baptiste Piacentino
Infrastructure to build and support Thunderbird will remain untouched
(Release Engineering, Web Services and Support services)." - On this last
sentence I would like to know how long we can expect them to remain
untouched considering the portion about staff above never really happened
as we expected?
I do not think Mozilla provided the above after that announcement so much
as this individual staff volunteered to do this work. I think asking
Mozilla to fund some of these roles and keep its commitment to provide the
resources it said would should not be out of the question.
Joshua as far as the things you ask it would be good to have answers to the
questions to and probably sooner than later but I also want to point out
some of those things are courtesies and were never suggested that they
would be offered or done so some of them we may need to just deal with
which would be unfortunate.
In talking with Mozilla (Mitchell et. al) I would encourage Kent to aim
high in the asks and hope for the best.
On Thu, Jan 8, 2015 at 2:07 PM, Joshua Cranmer 🐧 <Pidgeot18 at gmail.com>
> On 1/7/2015 4:18 PM, Kent James wrote:
>> 4) Some sort of official statement from Mozilla about Thunderbird's
>> status within the organization. I'm not exactly sure what I am looking for
>> here, but I have a sense that Mozilla staff don't really know how they
>> should react to Thunderbird anymore. We are not looking for Mozilla to fund
>> our activities, but we do need some recognition from Mozilla that
>> Thunderbird is an ongoing, important project that needs occasional
>> interaction with different parts of Mozilla.
> In my experience, the reactions of Firefox developers to Thunderbird range
> from "please also check to make sure that comm-central isn't affected" to
> "You're Thunderbird; fuck off." (To be fair, some of the people in the
> latter boat I suspect also have similar attitudes to add-on authors).
> What I think (sadly) is needed is explicit statements on what level of
> support mozilla-central developers should expect to provide for
> comm-central. For example, I would propose the following:
> A. If you're trying to ascertain if an interface, macro, class, etc. is
> used, and you're grepping through code using MXR or DXR, change the query
> from http://dxr.mozilla.org/mozilla-central to
> http://dxr.mozilla.org/comm-central. If there's a use in comm-central,
> and the change isn't an easy mass-change (example of easy mass-changes
> include things like the PRInt32 -> int32_t et al rewrites), file a bug or
> otherwise notify comm-central developers about the changes.
> B. If it's a mass change done by a script, please run the script on
> comm-central, or at least publish and make easy-to-run the script.
> C. If a mozilla-central change breaks a mozilla-central test but only when
> run in Thunderbird, the appropriate mozilla-central developers should be
> prepared to help diagnose and potentially fix the failure.
> D. High impact changes (e.g., changing load info semantics on channels)
> must be proactively announced in m.d.platform. Proactive means in at least
> enough time for affected consumers of relevant APIs to find and fix changes
> before the appropriate patches land on mozilla-central. It DOES NOT mean
> announcing them five days after landing.
> E. In certain portions of the codebase (e.g., the build system), patches
> that knowingly break comm-central are unacceptable. The onus is on
> comm-central developers to watch for breaking changes, but backing patches
> out from mozilla-central because of comm-central bustage is a potential
> recourse if no other option is easily admitted.
> F. If code in mozilla-central is needed by comm-central but otherwise
> unused by mozilla-central, and the mozilla-central developer wishes to
> cease maintenance of code, then the developer needs to alert comm-central
> developers to this fact and prepare the patches to import the code into
> comm-central, and to do this before removing code from mozilla-central. In
> turn, comm-central developers need to react in a timely manner to these
> These are the sorts of things that need hashing out--I don't like making
> it explicit, and I doubt Mozilla does either, but the ambiguity as to its
> level of support means that different people have different expectations of
> what is meant, and consequently you get several developers arguing that
> it's somebody else's problem.
> Joshua Cranmer
> Thunderbird and DXR developer
> Source code archæologist
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning