Thomas Goirand <thomas@goirand.fr> (08/05/2012): > This has already been discussed in -devel and in the PEAR list. That's > a mistake I did, and which will be fixed on next upload. I uploaded a > new version because I thought someone requested it from me, but in > fact, the package was already in Debian. Please ignore it, I will fix > that on the next upload and restore a correct changelog. Seeing such a thing makes me very sad. > Note that anyway, the package needed a big refresh as it was > unmaintained, even though marked as team maintained by the PEAR team. > So the arm is mainly the changelog itself, but not much more. Too bad that's the way we know if and when a bug has been fixed, in which version, and whether a NMU (and its bug fixes) have been ACKed or reverted. > I haven't done that work yet, because I don't want to do the work, and > then have the release team say no. I was asking if the proposed diff > to the upstream code would be acceptable. But if you are saying that's > ok, then I will do the work. You really don't like following standard procedures, right? Dully noted. > This is what I would have like to fix, because even a deprecation > warning can be annoying (especially when producing stuff like XML > documents where the warning breaks the integrity of such document). That's probably because I don't know a thing about PHP, but I'd tend to think the callers are (also) to be blamed if they can't handle those. > > We froze this weekend, so it's certainly not OK for this point > > release. > > Does this mean that I have to wait until the next point release is > out, in the event that you agree for the fix? Even if you think this change is totally harmless, I'd rather not see the behaviour of a given library in stable change, at all. I'd rather stick to considering targeted fixes for the callers, on a case by case basis. So, unless somebody feels fancy and wants to take it from here, that's a “no” for me. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature