On Wed, 11 Aug 2010 19:08:59 +0100
"Barak A. Pearlmutter" <barak@cs.nuim.ie> wrote:
> 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.
Policy will be applied with discretion, but the freeze is in place and
maintainers must now explain why their upload meets the criteria
outlined to d-d-a.
"correctness/robustness/performance fixes" is not a summary of changes
which would meet the criteria for a freeze exception. If that is the
level of discretion you require, you are looking for a situation where
there is simply no freeze at all. Every upload can (or arguably
should) meet those criteria - to have a freeze at all, this level of
such wishlist fixes must be denied an exception. If uploads to unstable
outside of a freeze do not result in "correctness/robustness and /or
performance" fixes then there is no reason for the maintainer to make
work for wanna-build in the first place. To fold so many wishlist fixes
into such a large diff makes it even less worthy of the exception.
http://lists.debian.org/debian-devel-announce/2010/08/msg00000.html
- fixes for release critical bugs (i.e., bugs of severity critical,
grave, and serious) in all packages;
- changes for release goals, if they are not invasive;
- fixes for severity: important bugs in packages of priority: optional
or extra, only when this can be done via unstable;
- translation updates and
- documentation fixes.
- pre-approved fixes.
- as above, important changes that the maintainer feels are *NEEDED*
before release
If any of those actually apply, please explain - with bug numbers
wherever possible. Otherwise, there is no reason for a freeze exception.
Exceptions are to fix Squeeze *and* avoid disruption by doing so, not
solely the avoidance of disruption.
Please explain how your package will fix problems in Squeeze within
the criteria set out above (which, AFAICT, are almost identical to those
from previous freezes).
> 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.
This is what is being done - any more permeable and we wouldn't really
be in freeze at all. The freeze will become harder as we get closer to
release.
> > 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.)
Just because you didn't personally see the results of making an early
announcement with a lag time before the actual release, does not mean
that those results were not seen by those who had to actually do the
work and that those results were deemed to be negative by those people.
> > 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.
So you would rather get the freeze exception and then have the package
removed from testing as soon as any bugs show up? How does that make
things any better for the release itself? Better to release with the
version that has already had some testing.
You can always backport to Squeeze after the release - put the upload
into experimental for now.
An exception is given in order to fix Squeeze and must do so without
causing undue disruption. Avoiding disruption alone is not sufficient
reason to get an exception.
> (Not that there is any real risk in the case of fossil, but that's
> beside the point.)
Is it? How can the release team know when the changes haven't been
explained and the diff is so large that it would be hard to see how it
would pass any level of freeze constraint.
OTOH you could make a better impression on the release team by fixing
some RC bugs in other packages instead of persisting with this little
diversion.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgpccDUQoK_6A.pgp
Description: PGP signature