This is actually an inherent problem with cvs. You cannot pull static tags by date. If you try to pull a static tag by date, nothing gets pulled. This means that we cannot reproduce builds from a previous day or week unless we have explicitly branched that portion of the tree. And since we need to be able to reproduce builds from day to day, we need to start using a branch tag instead of static tag for the version of NSS used by mozilla.
The NSS team only want to provide static tags to Mozilla client. If you need reproducible builds, we can use truly static tags and give you a new tag when a fix is checked in, e.g., NSS_CLIENT_TAG_X where X is a unique string. Now let's consider using a branch tag. We can't let you pull our stable release maintenance branch because then our checkins on that branch will be subject to Mozilla's tree closure. If you create a client branch of NSS, take charge of merging our static tags onto that branch, and guarantee that all the fixes you check in on the client branch are also given to the NSS team, that'll be fine. But, all this merging back and forth is extra work that we have wanted to avoid, and can you guarantee that all the fixes the client developers check in on the client branch are also given to the NSS team? Can a Mac developer, after a lengthy coding, debug, r=,sr=,a= process, always remember to generate a patch file and send it to the NSS team before he moves on the next P1 bug on his plate? Based on the NSPRPUB_CLIENT_BRANCH experience, I am pessimistic. So my recommendation is the truly static, NSS_CLIENT_TAG_X solution.
Why aren't you developing on the trunk, wtc?
The NSS_CLIENT_TAG_X solution would be better than what we have now but it still has the same problem that all static tags have. You cannot provide a fix for a build based upon the static tag without a) incorporating all of the current (experimental) development changes up to that point or b) creating a separate branch of that file explicitly for that fix. or c) waiting until the next release of the module with the fix incorporated a) & c) are bad from a consumer perspective, depending upon how far out the release is, and b) sounds like a maintenance nightmare. Just for clarification, while checkins to your development branches are not governed by mozilla tree rules, moving static tags are governed as they affect the build. You just brought up 3 different issues: 1) opening up the NSS partition to members outside the NSS team 2) policy enforcement 3) forking of development 1) Although allowing non-NSS members to check approved changes into the NSS partition would remove some of the burden from the NSS team (remove the bottleneck at a minimum), it's really outside of the scope of this bug. 2) Developers would still require r/sr from the NSS module owner before they could check in. If this doesn't happen, then inform drivers as this is purely a policy enforcement issue not a technical one. 3) You seem to be implying that by switching to the branch scenario that we would be forking the NSS development as there would be 2 sets of developers making changes. That was not the intent of this bug. Since NSS is truly a separate entity from Mozilla, who is responsible for the merging of changes will probably be forever under debate. For other Mozilla modules, the module owner is responsible for the merging and maintenance of the branches. There is no forking of the tree as the module owner would apply fixes to the branch used by Mozilla and their development branch simultaneously, if they are using a separate development branch. This is what I'm proposing for NSS. I do realize, however, that Mozilla is just one of many NSS clients and that this setup may not be appealing if you tried to apply it to N clients. However, if the mozilla developers will be responsible for the complete maintenance of that branch as you proposed then it will be effectively forked. At that point, NSS will become another absorbed 3rd party module like jpeg & zlib and we would probably end up sticking with released versions of NSS + interim fixes rather than trying to track changes made to the various NSS branches and static tags.
I am worried that we are arguing about a potential problem that is unlikely to bite us in practice. All the Mozilla milestone and release builds tag the NSPR, NSS, and LDAP C SDK they use and hence are reproducible. So we are really just talking about daily builds here. Because NSS_CLIENT_TAG is based on a NSS release branch, it is stable and checkins tend to be smaller and carefully reviewed. We have never had to back out a checkin in the NSS_CLIENT_TAG. Therefore it would appear that the inability to pull NSS_CLIENT_TAG by date, although unsettling, does not pose any real problem. So I propose that we continue to use the current model.
Marked the bug WONTFIX.
*** Bug 221138 has been marked as a duplicate of this bug. ***
This does present a problem. You are arguing, essentially, that your code is too good to ever be the source of a regression, and therefor pulling by date is unecessary. How is anyone supposed to be able to isolate what code is repsonsible for a particular regression without being able to reproduce the state of the trunk at any given instant in time? This is exactly how I came to file bug 221138.