Ehsan Akhgari wrote: > 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?
First, why don't we just create our own "moznspr.h" which declares the NSPR functions that are "allowed" in mozilla-central, using the standard C/C++ types? Since we know NSPR guarantees a stable ABI, this is more reasonable and safer to do for NSPR than it would be for other libraries. That might be better than making the NSPR header files themselves even more complicated by making (effectively) every feature disable-able with a configure flag or macro. > 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! I think this is one of the things where there is misunderstanding. Since I've joined Mozilla two years ago, I've found the NSPR and NSS teams to be very helpful in ensuring we get NSPR and NSS releases and betas finalized, with the features we need. I can only think of one issue where there was a delay in adding a feature to mozilla-central due to NSPR & NSS process, and that was actually caused by *review* overhead, not the release overhead. If there is work that is blocked on getting some NSPR or NSS feature added/patched in mozilla-central, it is really important that *I* know about it, in addition to Wan-Teh and Bob knowing about it. (Nearly) every Thursday I have a teleconference with Wan-Teh and Bob and other NSS team members where we talk about what is urgent to do and when NSPR and NSS releases need to happen and what the plan is for them. That is where I say "Mozilla really needs bug XXXXXX fixed in mozilla-central by date X, so let's make a plan for that." AFAICT, any delay here is caused by my misunderstanding of what "date X" is supposed to be, or me not knowing about the urgency of "bug XXXXXX." Generally, I understand what we need from NSS better than I understand what I need for NSPR. In the case of bug 563082, there is a comment (comment 10) saying it was blocking work in mozilla-central. But (a) that was in 2010 when we weren't doing rapid release, (b) there's no indication of what we consider the deadline, and (c) there's still no patch. If something is urgent for our needs then we should take the initiative of writing (and reviewing) the patch, and saying that we want to ensure that the next NSPR release will have that patch, and that we want to check in the patch to mozilla-central by date X. From there, we can decide whether it is better to tag a NSPR pre-release with the new feature and/or check in the patch concurrently to mozilla-central and the NSPR upstream, or what. Now, I definitely understand the concern about "How do I know if my patch will be accepted?" and I think that's better for Wan-Teh and Bob to answer. What *I* can say is that I've never had a significant problem in that respect, and I never worry about whether my patches will be accepted or not before I write them. But, also, I think it's good to make sure we're communicating clearly before we write patches, to save wasted effort--especially between the MoCo Mozillians and the non-MoCo Mozillians. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
