On 2012-10-11 8:52 PM, Wan-Teh Chang wrote:
Ehsan wrote:
It is entirely unreasonable to render ourselves unable to modify
our imported code (just look at the current situation with NSPR
which causes developers to go through huge pain in order to work
around things which would be very simply dealt with if only we
had the option of fixing NSPR...).
I don't know what the current situation with NSPR is. I guess I am not
reviewing patches fast enough. That's certainly my fault.
As for the option of fixing NSPR: you have that option.
NSPR public functions need to stay backward compatible. This means the
prototypes of public functions and the definitions of public types
cannot change. (There are exceptions, if done carefully.) Bugs in
function behavior can certainly be fixed.
Do we require to maintain source or binary compatibility, or both?
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?
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? I guess in a lot of cases we
just don't know whether NSPR would accept a patch if we make one, so we
end up implementing our own APIs.
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. This usually involves an amount of time which may not
be acceptable in our new 6-week cycles, which I believe is sometimes the
reason why people don't even bother submitting NSPR patches in the first
place and just resort to working around the problem (which is painful in
a lot of cases.) If there is anything that can be done in order to
streamline this process, it would be great!
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
