Prompted by a comment made by one of my potential sponsees, I've been reworking my semi-automated sponsorship queue from a "helps me" thing to a "could help lots of people" thing. The comment was along the lines of "wouldn't it be cool if we could remove the SPOF of sponsors, and have a group of people sponsoring packages".
Well, I'm to the point now where I think that I can make that happen. What I've got so far is an upload queue, a test autobuilder (to make sure that the package at least builds cleanly before wasting a sponsor's time with it), and the generation of a tarball containing the .dsc, everything that the .dsc references, and the build log from the test build. All of that is ticking along nicely, and I'd like to thank Lucas Wall and Juergen Strobel for throwing their packages at the queue for the last few days while I tweaked the bugs out of it. The final question I'd like feedback on is this: how many sponsors would consider pointing their sponsees to this service, rather than whatever methods you're using now? The benefits are that other sponsors might occasionally take a bit of your workload, and if you go on holidays / get sick / whatever, your sponsees aren't left to start from scratch. Another benefit could be that "occasional" uploads (such as NMUs and whatnot) could be handled by a team, rather than by lots of indiscriminate begging on d-mentors and elsewhere. BTW, if a large part of what I'm describing below sounds like mentors.debian.net, you're not alone. Looking back, it might have been easier to try and hack this into the m.d.n system. That might be where this all ends up. I don't know. One thing I'm not keen on is providing an apt-getable archive, and I also want to keep track of what's been sponsored and what's still waiting around - things that, AFAICT, m.d.n doesn't provide. The final step I'm planning on building into the system is a way for sponsors to get packages out of this queue system I've built so they can check them over and upload. The problem is, I'm not sure how to do this optimally. My constraints are: * Must be quick and simple to use. Too much hassle will cause sponsors not to use the system due to excessive pain. * I'd like (but it's not an absolute requirement) to be able to track who "claimed" each package for sponsorship, so sponsees can harass a particular someone if the upload never gets done. * Minimal manual intervention required on the administration side of things. Preferably no need for setup of accounts beyond that provided by a GPG public key. * Once selected by a sponsor, a package for sponsorship is taken "off the market" for others, but can be reinstated later if the original downloader can't upload, but the package shouldn't be rejected. * If possible, sponsors should be able to select a package they want to check and upload, rather than being given the "next in the queue". For instance, I'm not qualified to sponsor java packages, and I'm sure others are in the same boat. * As simple to implement as possible. Duh. So, given all of that, I've got two different ways thought up. Both suck, but in different ways. 1) E-mail. Sponsors send a GPG signed e-mail to a request address, get the next package on the list e-mailed back to them. They could also request a particular package, and if it's available, they'll get that. Fails the "select" part badly, but can be hacked to do most everything else. But who wants multi-megabyte files in their inbox, hmm? 2) Web. Surprise! Makes the tracking stuff harder (probably need to go to a login-based approach - yay, another password to remember/manage) but simplifies the package selection and downloads won't be quite so horrendous. Easier for me to implement because it's what I get paid to write (webapps). There have also been thoughts of mutant hybrids flying through my brain, where you list on the web and send e-mail to retrieve, then get a URL to download, but these have, well, severely limited attractiveness for me. But it's another possibility. How about an e-mail to get the list of packages, then reply with the one you want, and you get back a URL to download the one you want. Ugly, though, and I'd need to write code to parse MIME for the GPG signatures (more Python learning, I guess). So, comments, brickbats, acclaim, whatever. Throw it at me. - Matt
