Bug#689157: unblock: mediawiki-extensions/2.8
On Sat, 2012-09-29 at 17:50 +0200, Thorsten Glaser wrote:
Before we get in to the body of your mail:
mediawiki-extensions (2.6+wheezy1 to 2.8)
mediawiki-extensions-base (i386, amd64, armel, armhf, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc) has new bugs!
Updating mediawiki-extensions-base introduces new bugs: #686190
Asking for an unblock that reintroduces an RC bug in to wheezy is a
little unusual, to say the least.
> As for diffs: mediawiki-extensions/2.7 was the first version to
> properly work with MediaWiki 1.19, 2.6 and below were for 1.15,
> and, despite some trickery leading to 2.6+wheezy1, are not at
> all suitable for it (I said in #686190 that it was just the be‐
> ginning, and #687641 being filed proved me right).
That upload was made by one of your co-maintainers. I'm not sure if it
was intended, but describing it as "trickery" does not create a very
> Furthermore, mediawiki-extensions/2.7 was waiting for migration
> to testing for more than 60 (sixty) days already, depending in‐
> directly on nodejs due to ECMAscript compression and one of the
> affected libraries being a dependency¹, and the JS packagers as
> well as I were under the impression, all the time, that we could
> have this fixed for wheezy, until being told, IMO much too late,
> that this would not be accepted.
Assumption is a dangerous creature. I'm not aware of anyone from the
release team ever suggesting that they would be accepted and I thought
our policy on adding new packages to the release during the freeze was
If people were relying on nodejs and anything depending on it being
given freeze exceptions, that should have been discussed with us
beforehand, not assumed.
> So I respectfully ask that the
> Release Team consider mediawiki-extensions/2.7 already accepted
> and just not transitioned due to misinformation.
There was no misinformation, at least on the part of the release team.
If you believe there was, please provide documentary evidence of such.
There appears to have been a misunderstanding, but I'm not convinced
that qualifies for ignoring changes relative to the current wheezy
> ① As it turns out, that dependency was not even needed in the
> end; the 2.8 upload removes it. But I was left in good faith
> that 2.7 would transition as-is, and we could fix all follow-
> up problems later.
"Good faith" again implies that it was suggested that nodejs and
associated packages would be given exceptions (one can't get good faith
from an assumption). I'm not aware of that ever having been the case.