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

counterproductive, gratuitous uploads of imagemagick



Ryuichi-san,

You just uploaded version 6.0.7.1 of imagemagick to unstable with the
justification:

   * New upstream release
     Upstream authors applied the patch,  by Daniel Kobras,
     which fixes BMP vulnerabilities assigned CAN-2004-0827
     (http://studio.imagemagick.org/pipermail/magick-developers/2004-August/002011.html).

This is NOT the version of imagemagick which fixes this bug; the bug was
already fixed in 6.0.6.2, which you uploaded to unstable over a week
ago!

This is made clear by the URL you linked to in the changelog, which
points to ImageMagick 6.0.6.

This is also made clear by bug 268357, which was opened by Daniel Kobras
himself to track the status of this issue in testing.

You uploaded a new version of imagemagick *less than 24 hours before
this security fix was due to reach testing*.  You have now reset the
waiting period for this package, and forced rebuilds on all
architectures before this security fix can reach testing.

The *last* new upstream version you uploaded, 6.0.6.2, fixed a security
hole -- but it also made the package unusable on ia64, requiring a lot
of developer time to track down and making other packages fail to build.

We have no idea what problems *this* new upstream version may cause; we
may not even have a chance to find out before releasing whether this
version introduces new arch-specific breakage.

This is not appropriate handling of a package with 61
reverse-dependencies and countless indirect reverse-dependencies while
we are trying to freeze for release!


ImageMagick 6.0 was accepted into unstable on 15 Apr 2004, and there
have been almost weekly uploads since then -- including uploads of 20
new upstream releases -- with no breaks long enough to let this package
and the packages depending on it into testing.  Even once the libtiff
transition was announced, you made *two more uploads of new upstream
releases* while we were trying to get all of the packages into a state
where they could be moved into testing.

This is not appropriate handling of a package with 61
reverse-dependencies at *any* time during a release cycle!


The goal of package maintenance is not to get the latest upstream
version into Debian; the goal of package maintenance is to contribute
to a quality operating system.  It is very difficult to assure the
quality of a component that changes every week, as ImageMagick has done
since at least April.


Library maintainers:  please remember that you are not working in
isolation.  You have an obligation to pay attention to the needs of
maintainers of packages that depend on yours, who are *users* of your
package!

-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: