Saturday, 18 July 2009

The Mountain View Public Library is a really fantastic public library. A little while ago, they redid the check out system and switched to using RFID for everything. I can walk in check out books and walk out again without having to interact with anyone.

I put a hold request for a book recently via the library's website, and it came in a few days ago, and just popped down to pick it up. All of the books on hold for people are on a set of shelves in the "holds" section, with a bit of paper sticking out of them with your name on it.

I was ferreting around these shelves, trying to find the P's, when I overheard a woman remarking semi-shocked to her husband about the privacy implications. She commented to a librarian stocking shelves nearby about how she worked in library in Fort Lauderdale, and weren't they concerned about privacy and everyone seeing what these people were reading? The librarian said that she guessed not.

I must have low privacy standards (or I guess everyone else who puts holds on books in the library does as well) because I really can't see a problem with the way the holds are done.

It would be horribly inefficient to have to ask at the counter for my book (the holds section would have had easily a hundred books on the shelves). The bit of paper has my name on it. Granted, it has a fraction of my middle name, so it's a little more personally identifying than it perhaps needs to be, but either way, I don't consider it a terrible invasion of my privacy.

As it was, I was able to walk in, find my book, use a self-checkout machine and walk out again. For that convenience, I'm prepared to lose a little bit of privacy if someone wants to spend all day, every day, casing the holds section of the library just to try and figure out that I'm reading Good calories, bad calories

I discovered last night (and it was possibly a rediscovery) that packages that produce udebs seem to be perpetually frozen, and require manual approval from debian-release and debian-boot to enter testing.

I swear that once upon a time, this was only the case around releases, but now it seems to be the case all the time.

I view this as a serious disincentive to make a udeb from a package that also operates outside of debian-installer.

I noticed the problem when I made a high priority upload of dhcp3 to unstable to fix CVE-2009-0692, with the expectation that it would hit testing within a couple of days. When about 3 days had passed without an email from the PTS saying the package had entered testing, I pulled out the trusty grep-excuses, and (re)discovered the freeze for udeb-generating packages.

I think if debian-boot is going to mandate this freeze for udeb-generating packages, then someone on debian-boot should be getting a report every day of udeb-generating packages that are due to enter testing in the next 24-48 hours, so they can be proactively vetted and their entry into testing not delayed unnecessarily. It shouldn't have to fall on me as the package maintainer to have to notice.

I've gone and forgotten again the reason for this freeze in the first place (I've had it explained to me a couple of times, it's possibly due to #271782, which last saw activity four years ago), but every time I'm told "oh, it won't be this way much longer". It's been this way for literally years. Show me the plan to make it different.