Re: freeze exception: fossil 2010.08.05.100943-1

["Barak A. Pearlmutter" <barak@cs.nuim.ie>]

Well, certainly I do understand the policy as written.  I suppose I
was assuming that it would be applied with a great deal of discretion
early in the freeze, and become more stringent as time went on.

I suppose I do not agree that such an extremely binary policy, phased
in so abruptly, is optimal: I would argue that starting with a very
permeable barrier, and gradually hardening it, would make more sense.

> 1) "it has been done before and it didn't hurt the release" is not
>    an argument.  We can review our rules/practices and change them
>    if it's a good idea for the release.

Of course that's a good argument!  What could possibly be a better
argument?  I don't understand what you mean.  How could the contention
"We need stricter laws against X" not be undermined by actual
experience that, when X was permitted, it was not a problem?  (In this
case, X = low barrier to allowing new upstream versions of new leaf
packages while in early freeze.)

> 2) "it's a leaf package, it won't hurt anyting" is not an argument
>    neither. We have the same quality expectations for leaf packages
>    and packages with lots of reverse dependencies.

I feel like we're living in different dimensions or something.

It is a reasonable argument because dealing with the *consequences* of
a poor quality package is much less difficult in the new leaf package
case.  Since dealing with the consequences of such an error is so
simple, we should be more willing to risk *making* such an error.

(Not that there is any real risk in the case of fossil, but that's
beside the point.)

					--Barak.