I'd like some enlightment about the relationship between Mozilla trunk and NSS trunk, and Mozilla release and NSS release.
NSS is used by many products, of which the mozilla browser is merely one. The mozilla trunk often gets into a "closed" or "frozen" state where no checkins are allowed, etc, which is appropriate for the browser but not for NSS. NSS developers need to continue to be able to checkin on NSS's trunk when mozilla's trunk is "closed" to checkins. So it is necessary to decouple the NSS trunk (and its control) from the mozilla browser trunk and its control.
NSS produces numeric releases with some frequency. We produce a "minor" release (e.g. 3.8, 3.9) about twice a year and a "point" release "e.g. 3.8.1) more frequently. We make a branch just before or just after each "minor" release. point releases are made off of the branch for the minor release on which they are based. The NSS trunk nearly always says it is the "NSS 3.XX BETA" build, and the branches nearly always say they are the "NSS 3.xx.xx BETA" build. This is to prevent an NSS build from the trunk or from the tip of one of the brances from being confused with a real release build.
To ensure that a checkin on the NSS trunk does not break a mozilla browser build, every mozilla browser build pulls NSS sources from one of NSS's CVS tags. There is an NSS CVS tag for every NSS release, including major, minor and point releases. Every mozilla "alpha" (e.g. 1.7a), "beta" (e.g. 1.7b) or release (e.g. 1.7) is supposed to pull NSS from a tag, such as NSS_3_9_RTM or NSS_3_8_3_RTM. (RTM means "Released to Manufacturing"). Those tags do not change once they are created.
There is also a special tag named "NSS_CLIENT_TAG". This special tag moves along the NSS trunk, but is updated rather infrequently, e.g. about 2-3x/month, I think). mozilla browser nightly trunk builds pull NSS source from that tag. This allows mozilla nightly builds to obtain recent NSS trunk changes in a controlled fashion, and ensures that an NSS checkin on the trunk will not break any mozilla build.
People who make mozilla releases (including alpha and betas) are responsible to ensure that they build those releases with an official NSS release tag, and not with the "NSS_CLIENT_TAG". When a new mozilla branch is created, it is a simple thing to create a branch of NSS with the same same as the mozilla branch (that is, to make NSS part of that new mozilla branch), and to make the NSS branch occur at the then-current setting of NSS_CLIENT_TAG.
This has all worked fine for years now, and I am surprised at the recent vociferous attack on this scheme. Perhaps someone didn't understand how it works.
Wan-Teh Chang recently said here that in order to include the fix from bug 53133 in Mozilla 1.7b a new release of NSS (3.9.1) would be required, as it has been fixed after NSS 3.9 was released.
Right. If the moz browser folks are doing things right, they will ensure that 1.7b is built from an NSS tag other than NSS_CLIENT_TAG. To put it another way, if a mozilla release ever shipped with NSS built from the NSS_CLIENT_TAG, that would (IMO) be an error of the mozilla builders, and not of anyone in NSS.
If the mozilla builders want the next beta build to include the fixes now on the NSS trunk, we will have to make an NSS point release to include them for that beta. I think Wan-Teh is planning to do just that.
This seems to imply that Mozilla is built from a stable version of NSS, and the changes from NSS are only included inside Mozilla trunk after a stable version of NSS is produced.
mozilla releases are built from stable released versions of NSS. The nightly mozilla trunk builds use a tag that is not set in stone, just as the nightly mozilla builds themselves are not set in stone.
*But* I could test with a Mozilla nightly ID 20040202 that the fix from bug 53133 is effective, and I just checked visually that the line from the bug 53133 patch are present inside the file mozilla.org/mozilla/nightly/latest-trunk/mozilla-source.tar.bz2 from today.
This is the same file as nightly/latest as the trunk hasn't yet forked for 1.7a.
So is NSS trunk directly included inside Mozilla trunk by error ?
No.
Or does this mean that the NSS trunk is inside the nightlies for testing purpose, but that there will be a roll-back to the latest stable NSS release, when Mozilla 1.7 is released ?
mozilla nightlies build from a recent snapshot of the NSS trunk. When a moz release is done, NSS typically rolls forward to a new point release, rather than rolling back.
Maybe by way of a roll-back inside the Mozilla 1.7x branch when it has forked from the trunk ?
The good thing in having the NSS trunk inside the Mozilla nightlies is that a lot more people can test it, and I wish it could stay that way.
Is it not staying that way?
The only weakness in this system, known to me, is that there is no web page or other easy to find table showing moz releases, and the corresponding version numbers of NSS.
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
