Thu, 26 Jun 2003
One of the tricks with paying for http requests is that you screw up the protocol. Normal http requests are a simple request/response pair, and that’s it – you ask for a page, and you get given it. Worse, the protocol is optimised for that: if you want to do more than just send a request, you usually have to open additional connections for each, which has a significant overhead.
The easiest way to work around this, is probably to make the protocol for requesting a webpage be to send a HEAD request, which will confirm the webpage exists and that you don’t have a current cached copy and can also tell you how much it costs to download, and then send a GET request with the appropriate ecoin as a header. With HTTP/1.1 you can, I believe, make persistant connections to make this possible. I think this is also optimally efficient, and involves minimal changes to the protocol. (There’s even a “Payment required” error code, how convenient)
What would be really cool, is an aggregator that can collect your various favourite RSS feeds, categorise them (by author, and by subtopic), your various favourite webcomics, and random other information (weather at least) and present it in a “newspapery” format. That’s “really cool” in the “not necessarily effective, pleasant or useful” sense, of course.
Is it just me, or is there something really unpleasant about seeing huge blocks of text in a blog, that aren’t broken up by pictures, or new headings or quotes from elsewhere? I suppose a “…read more” link would work, but I tend to find that a real nuisance. I wonder why I don’t mind Steven den Beste’s site, since it’s mostly long essays. Actually, Steven’s site is broken up – by updates in different font sizes, and cites and links to source material, and the occassional picture. And there are bits of gray on both sides of his page, and a pretty picture at the top. Maybe that’s the trick: have a picture at the top to catch your eye, then once they get into the reading, they don’t care that it’s not pretty.
(For those coming in late, “britney” is the name of the scripts that manage Debian’s testing distribution; it uses a number of criteria, including time since upload, number of open bugs, where it’s been ported to, and dependency information to maintain a set of packages that meet Debian’s release goals. I’m the Debian release manager at the moment, and britney’s my baby. See also: Debian, testing distro, RC bugs.
The biggest problem with britney at the moment seems to be that people aren’t taking the hint to fix release-critical bugs throughout the release cycle. That causes individual packages to get stuck, which then causes other packages to get stuck, and causes a huge logjam. Unfortunately “testing” itself is evidently not enough of an incentive (by letting people get their updates into a “released” distribution within 10 days) for people to fix RC bugs quickly, so we probably need to setup some new ones.
One idea is to mess with Britney’s delaying tactics some more. Really, ten days is frequently too long a period (for people like Joey Hess, who make minor updates to many of his packages every few days), and even more frequently far too short a period (we don’t really have a reliable QA group finding problems and we’ve even gotten to the point where people can tend not to bother filing bugs under the expectation they won’t be fixed anyway, with the result being that packages get into testing in spite of still having serious bugs).
Two factors thus influence the delay: we want to get packages into testing fairly quickly so that people can start working on new stuff in unstable (and so people following testing get the latest updates), but we want them to stay in unstable for a little while so that we can have some confidence the package isn’t too horrible. The idea, then, is to delay every package exactly long enough to find all its RC bugs. There are obvious problems with the knowability of that, so instead we need to make it proportional to the “riskiness” of the package, which is roughly proportional to how long it’s been since the last major changes.
So if you upload version 2.0-1 on the 1st which is a major rewrite, and 2.1-1 on the 4th with some minor changes to the documentation, you’ve got a high risk - and long delay - carried on from 2.0-1, and a small risk and a low delay beginning with 2.0-2. If you upload 2.1-2 with a couple of packaging changes a month later, your previous risks have run out, so you’ve only got a very small risk, and a small delay, left. The delays could then look like:
The question then is how to work out what a risky change is. One way is just to have the maintainer nominate a value in the changelog, and keep track of that in a similar way to how urgency values are already tracked. This should work mostly, but probably needs to be supplemented by something a little less discretionary. Another option would be to say that every change that fixes an RC bug is a major one. That’s probably justifiable (at the very least, it should be true that the change that caused the RC bug was major, and making the delay start at the time the fix is uploaded instead of the bug shouldn’t be too troublesome.
Another thing you could do is allow people to review changes, and having done so, mark them as less risky. So it might take 30 days of sitting in unstable for X 4.3 to be considered acceptable for testing, but the QA team, having looked over the patches, and taken into account other things might be willing to vouch for it, and get it in after only 20 or 15 days.
Hrm. While that provides some extra incentives, and I think some more sense in the time, I don’t think it’s remotely close to solving the real problem of getting packages better maintained.
Looks like today’s the day to move the old azure to the new azure! Ooo, the excitement! The terror! Will all my mail scatter to the nether regions, lost until the great cleaners reclaim the bits next April? Soon we shall find out!