How to read text in somebody's text which is not there, and not meant to be there - or: dunc-tank didn't slow down Etch
That sometimes journalists have obvious reading problems, well, isn't a too new thing. One has to deal with that, e.g. by appending more text to the cited blog entry.
If someone inside the Debian community fails for the same is way more disappointing for me. I have never stated that "[I] couldn't compensate this" - that is just totally wrong. I think that dunc-tank helped us with release of Etch, but the help could have been greater if some people wouldn't behave as childish as they do. And I also try to look both ways, and not be singled-minded about it.
There is another thing I learned as well during the last 12 hours - people don't appreciate if one tries to summarise openly what happened, and look both ways. Is it so wrong to look in both directions, and not only say "that and that were the improvements"? I thought at least within Debian we don't want to fall the usual management mistake of only speaking about how great everything is, but be honest to ourselfs. People starting to rip only half of the words out, citing them out of the context, and inventing new quotes don't help with that.
attr and libpng
Monday morning started with seeing lots of brand new release bugs about attr being broken so bad that "ls -la" failed, and also buildds were affected negatively. As a consequence, I few-hour-NMUed this package back to a sane (i.e. working) state. As any library maintainer, please remember: Whenever you drop a symbol - whichever this symbol is this means: You need to bump SONAME. Or just use library versioning from the beginning. Failing to do so can lead break any program linking to your code, which is especially bad if it is ls and cp.
Rest of the day was mostly spent on further libpng-analysis. There is now a nice table on http://ries.debian.org/~aba/png.abis which symbols were exported in which version. We are progressing into resolving the libpng problems now.