84435 - Cannot pull nss client tag by date

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[cls]

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.

Comment 1

[Wan-Teh Chang]

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.

Comment 2

[Chris Waterson]

Why aren't you developing on the trunk, wtc?

Comment 3

[cls]

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.

Comment 4

[Wan-Teh Chang]

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.

Comment 5

[Wan-Teh Chang]

Marked the bug WONTFIX.

Comment 6

[Wan-Teh Chang]

*** Bug 221138 has been marked as a duplicate of this bug. ***

Comment 7

[Jerry Baker]

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.