Hi Ehsan, Thank you for your reply.
On Fri, Oct 12, 2012 at 7:25 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > > Do we require to maintain source or binary compatibility, or both? As BDS said, both are required in general. Source compatibility can be broken if it is not disruptive, and that's often hard to assess. This is the case for the OpenBSD integer type problem. > Also, is it acceptable for us to add new preprocessor definitions such as > NO_NSPR_10_SUPPORT to optionally remove some of the NSPR feature which we > would like Gecko to avoid, without changing the default set of names > declared in NSPR headers? Yes! In fact I recommend that we compile Mozilla code with -DNO_NSPR_10_SUPPORT. > In some cases in the past (such as bug 563082), we've needed to change the > semantics of some of the NSPR functions to make them work better for some > things, such as more precise time measurements, but we've had to implement > our own APIs (e.g., > http://mxr.mozilla.org/mozilla-central/source/xpcom/ds/TimeStamp_windows.cpp) > which we've since heavily optimized (for example, in bug 784859). Would > such improvements be interesting to NSPR? Yes, such improvements would definitely be interesting to NSPR. Note that the semantics change must be allowed by the specification of the function. In the case of bug 563082, changing the underlying Win32 function from timeGetTime to QueryPerformanceCounter is allowed by the specification of PRIntervalTime because the time resolution is specified to be platform dependent. > Another issue which I think sometimes prevents us from fixing things in NSPR > is that the process usually looks like submitting the patch to NSPR, getting > it reviewed, then wait until the next NSPR release (which we don't know when > will happen), then import the new release into mozilla-central. Yes, this is the proper process. However, recently we created a process for Mozilla to apply temporary patches before a new NSPR or NSS CVS tag is pushed. See Step 4 in https://developer.mozilla.org/en-US/docs/Updating_NSPR_or_NSS_in_mozilla-central All I ask of Mozilla developers is: 1) Prefer pushing NSPR/NSS tags over applying temporary patches. 2) If temporary patches are used, properly document them. We can make a new NSPR release quickly. If I am busy, several other people (Brian Smith, Kai Engert, and possibly Ted) know how to do that. Wan-Teh _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform