[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Multi-person sponsorship



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



Reply to: