Randell quoted: > 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...).
First, I think that a lot of Mozillian's concerns about how we can(not) change NSPR and NSS are based on old events and circumstances that do not apply now. For example, the time where NSS 3.whatever was being FIPS validated seemed to cause a lot of unfortunate misunderstandings all around. But, that was literally years ago. I encourage people to be more optimistic about things NSPR and NSS related. And, please keep in mind that there is already progress being made (if not a definitive agreement) on the Mercurial vs. CVS issue. There is a very practical reason for avoiding making private changes to NSPR and NSS. The most obvious reason is that it makes it esay to merge changes between upstream and our codebase. However, the more critical reason is that we support --use-system-nss and --use-system-nspr, and some Linux developers build their Firefox packages with those options. As long as we support --use-system-nss and --use-system-nspr, we need to make sure the upstream NSPR and NSS contain every bugfix and every feature that we require. If we were to give up on the idea of supporting --use-system-nspr and --use-system-nss, then we could gain more flexibility in how we change NSPR and/or NSS in mozilla-central. However, at least in theory, --use-system-nss and --use-system-nspr should be superior performance-wise, on Linux, because usually the system NSPR and NSS libraries are already loaded before Firefox starts. Thus, our startup time should be lower. Also, according to some conversation on dev-tech-crypto, the system NSS may eventually provide better platform integration regarding centralized certificate and smartcard handling, allowing us to share various security-related features with other applications (between Firefox and Thunderbird, or Firefox and whatever-the-Gnome-email-app-is). So, I think there are still advantages to supporting system NSS. In the event that we really do need to make private changes to NSPR and NSS, we should be able to do so. I think there's been a lot of unnecessary misunderstanding about this. If you *need* a change made to NSPR or NSS before we're ready to make a NSPR or NSS release, please make sure that the NSPR and NSS teams are aware of that, so we can help. And, whenever possible, try to avoid creating emergency situations. I have found everybody to be quite reasonable about it, especially when my request didn't involve me needing them to drop their work to do a code review for me. Usually we upstream those changes into NSS and NSPR first, because we need NSPR and NSS peers to do the review anyway. We try to avoid making "temporary" fixes only in mozilla-central, because, well, what happens if they don't get accepted upstream? Then we've broken --use-system-nspr and --use-system-nss. Still, I think there is more flexibility here than people realize. In general, it is harder to get changes made to NSS and NSPR than it is to get changes made to the rest of Gecko. One reason is that the reviewing standards are different/stricter in these modules than they are in some/many (but not all) Gecko modules. I actually prefer the stricter NSPR/NSS reviews and I hope that doesn't change. Another reason is that, generally mozilla-central is primarily geared towards Mozilla products (especially Firefox), whereas NSPR and NSS are shared between us, Chrome, and all Linux distributions. NSPR and NSS are part of the Linux Standard Base, which means that it is difficult to make compatibility-breaking changes to them. Sometimes when people suggest changes to NSPR and/or NSS, it isn't clear how urgent that change is. Definitely, I have sat on a review for too long because I didn't realize it was actually as urgent as other work I am doing. Because many of the NSPR and NSS peers do not work for Mozilla, and do not work on Mozilla stuff full-time, it definitely isn't as obvious to them what is a high-priority request and what isn't. And, also, because they have their own jobs and their own schedules, sometimes schedules are not aligned as well as we would like/need them to be. IMO, the solution to that is to have more MoCo employees and other Mozillians become peers on the NSPR and NSS projects, so that we can help with the code reviews in these projects. I know on the NSS part, we're definitely trying to make progress in getting more Mozilla people involved. For NSPR, my understanding is that we're generally migrating away from using NSPR in Gecko, except for networking. Lots of stuff that's in NSPR already has replacements in mfbt and/or in ISO C/C++. One reason for doing this is that we can make use of C++ features in mozilla-central. Another is that we have more flexibility for making changes. Even though I think NSPR is an excellent library, I think the trend away from using NSPR in Gecko is a good thing, because we can use C++, and ISO standard APIs, if nothing else. So, I think the changes Mozilla wants to make in NSPR are pretty minimal already. But, definitely, it would be useful to know what changes to NSPR are considered high priorities for Mozilla. I've already brought up the prtypes issue. Are there others? Suggestions, questions, and comments are encouraged, (politeness++)++ please. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
