[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#606067: marked as done (unblock: cl-asdf/2:2.011-1)

Your message dated Sun, 19 Dec 2010 14:47:46 +0000
with message-id <1292770066.31121.6720.camel@hathi.jungle.funky-badger.org>
and subject line Re: Bug#606067: unblock: cl-asdf/2:2.011-1
has caused the Debian Bug report #606067,
regarding unblock: cl-asdf/2:2.011-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

606067: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606067
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock

Please unblock package cl-asdf

cl-asdf (2:2.011-1) unstable; urgency=low

  * Mostly same as 2.010.9: several minor tweaks and bug fixes since 2.010.
  * Will be happier: users of implementations ACL, GCL; users of libraries
    CL-Launch, XCVB; future former users of ASDF-Binary-Locations; people
    with missing dependencies (in lieu of error-in-error); people extending
    ASDF (notably Stelian Ionescu), who'd like to use keywords to name
    component classes.

 -- Francois-Rene Rideau <fare@tunes.org>  Sun, 28 Nov 2010 13:21:34 -0500

cl-asdf (2:2.010-1) unstable; urgency=low

  * same as 2.146

 -- Francois-Rene Rideau <fare@tunes.org>  Thu, 28 Oct 2010 15:58:36 -0700

cl-asdf (2:2.009-1) unstable; urgency=low

  * new upstream release 2.009, identical to 2.134 from master.

 -- Francois-Rene Rideau <fare@tunes.org>  Wed, 06 Oct 2010 13:26:36 -0400

cl-asdf (2:2.008-1) unstable; urgency=low

  * new upstream: removes unwanted exports,
    plays nicer with sbcl, cmucl, old clisp.

 -- Francois-Rene Rideau <fare@tunes.org>  Fri, 10 Sep 2010 17:16:06 -0400

cl-asdf (2:2.007-1) unstable; urgency=low

  * new upstream, fixes lp#623992 introduced in 2.006, allows upgrade on SBCL.

 -- Francois-Rene Rideau <fare@tunes.org>  Wed, 25 Aug 2010 23:22:13 -0400

cl-asdf (2:2.006-1) unstable; urgency=low

  * new upstream, with bug fixes and API changes.

 -- Francois-Rene Rideau <fare@tunes.org>  Tue, 24 Aug 2010 18:43:48 -0400

cl-asdf (2:2.005-1) unstable; urgency=low

  * New upstream.
  * Don't use dh-lisp

 -- Francois-Rene Rideau <fare@tunes.org>  Tue, 17 Aug 2010 13:57:04 -0400

unblock cl-asdf/2:2.011-1

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

--- End Message ---
--- Begin Message ---
On Sun, 2010-12-19 at 13:51 +0800, Desmond O. Chang wrote:
> On Sat, Dec 18, 2010 at 23:29, Adam D. Barratt <adam@adam-barratt.org.uk> wrote:
> >
> > Most of his answer seemed to be about why we should accept the newer
> > version of cl-asdf rather than the source format change; "lintian didn't
> > like the empty diff.gz" and "people on IRC told me to do it" aren't the
> > greatest of reasonings either.
> What's wrong with the 3.0?  Why is it so hard to change?

The relevant question isn't "what's wrong with 3.0", rather "what's
wrong with packaging changes when requesting an unblock".  The answer is
the same whether the change is to the source format, debhelper compat
level, addition or change of a patch system or other similar changes -
they add the potential for issues to be missed when reviewing the diff,
either because a small change has larger implications than it first
appears, or because the changes are only visible in the generated binary
packages, not in the source package.

The "3.0 (quilt)" format also makes diffs harder to review if
maintainers don't keep all of the changes made to the package in quilt
patches.  In this case, dpkg automatically generates a
debian-changes-$version patch which includes all the remaining changes;
even if the changes being made remain constant, the patch will change
name with every new upload, making a simple review more complicated - it
could be argued that this is a deficiency in the tools used for review,
which is to some extent true.

In this particular case, the fact that there are no local patches
against the upstream source and a single upstream tarball makes the
advantages of "3.0 (quilt)" rather redundant.  The Debian package also
clearly /has/ derived from upstream previously, as the version currently
in Squeeze has a non-empty .diff.gz.

However, the lack of patches also means that the source format change is
largely a no-op in this case.

I've unblocked the package, but *only* because it is blocking the
migration of RC fixes in other packages.



--- End Message ---

Reply to: