Re: Multi-person sponsorship
Matthew Palmer <mpalmer@debian.org> writes:
> 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.
What kind of security do you have to prevent uploads of malicious
sources?
I hope you destroy the chroot after each build and unpack it anew.
Having a new-maintainer keyring, to which keys could get added by any
AM after it has been verified, and checking the signature on the dsc
files against it sounds good to. And the keyring would be usefull for
other purposes too.
> 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.
I like it.
> 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.
It would be nice if some uncommon archs could have a buildd for this
so new maintainers are faced with protability right from the start.
> 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.
A mini-dinstall apt repository with limitd access. Accounts could be
activated once by signed mail stating a user/pass pair.
> * 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.
Sponsoring could work just like the normal buildds. The sponsor sends
a mail back to the buildd with the signature and the buildd does the
uploading. There could be a simple webpage where DDs can claim
packages for a limited time (say 24h default with a 1 week option)
with a simple click. The webpage could double at showing whats
available for sponsoring too.
> * 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.
A mail wrapper could check against the debian keyring and activate
accounts fully automatic then.
> * 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.
Unless its rejected by the sponsor (with an explaination) or a newer
version is uploaded. I think if the sponsor finds problems with a
package it shouldn't go back just because some time passed. Packages
should automatically come pack when no action is taken by the sponsor
though.
> * 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).
I think an apt repository for the build packages would be easiest to
quickly test packages. Access should be limited (account creation by
signed mails) and the pin setup like experimental to prevent
accidentaly installing debs from there.
You could track who downloads each deb and show a counter on a
overview page. That could be used as an intrest indicator. ("Yes, 2
people have tried my package, lets see if one is willing to sponsor
me"). Intrested sponsors could claim the package on that same page,
which would remove the "needs sponsor" flag for a limited time.
> So, comments, brickbats, acclaim, whatever. Throw it at me.
>
> - Matt
Please do keep at this, if you can pull it off I think it will improve
the sponsoring greatly.
MfG
Goswin
PS: I'm still looking for someone to sponsor debix (a debian life
filesystem+creator+installer), version 1.0 is coming up.
Reply to: