On 2012-10-12 12:18 PM, Wan-Teh Chang wrote:
Hi Ehsan,
Thank you for your reply.
Hi! Thank you for your swift replies too! :-)
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.
OK, that's fair. However I wonder if we can take a local patch for that
to out copy of NSPR since (unless I'm missing something) that will not
involve any binary compatibility problems for Gecko.
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.
We're in fact working on that very hard in bug 794510. :-) I will
definitely keep this in mind if we decide to disallow an NSPR API in
Gecko in the future.
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.
I see. I've commented in bug 563082 in case someone looks at it in the
future.
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.
Oh, this is extremely useful! The MDN page talks about how maintaining
local patches would work for NSS. Do we also have a similar policy for
NSPR? If yes, I'd be more than happy to write a local patch for bug
634793 to help us alleviate the OpenBSD problem we're facing without
causing compatibility problems for the rest of NSPR consumers.
Thanks!
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
