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

Re: Multi-person sponsorship



On Tue, Feb 17, 2004 at 08:45:00AM -0700, Jamin W. Collins wrote:
> > 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 the automatic build testing, but would like to stress that these
> packages would still need installation and usage testing.

Oh, absolutely.  That's one of the reasons I'm not real keen on providing
pre-built debs and such (apart from the wasted bandwidth) - at least this
way, hopefully, sponsors will spend the extra time looking over the package
before uploading.

> Could create an upload queue similar to Debian's current ftp uploads.  I
> would check the upload to see if it's signed by a developer's key.  If
> so, it could remove the package from your queue and forward the signed
> upload on to Debian's upload queue.

That has a certain elegance to it.  Thanks!

> > 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).
> 
> I would prefer this approach.

OK.

This is what I've come to so far:

1) Login management for downloading packages (I'm not keen on open slather
for downloads) via GPG-signed e-mail.

2) Download tracking, both by count and "yes I'll upload this" via web
browser.  I'm still up in the air about whether there will be apt-getable
resources, or whether pre-built binary debs will be accessable.  I don't
particularly want to be a general "out of Debian" apt-get repository, there
are plenty of those - mentors.d.n being the closest match here.  What I want
to provide is a sponsorship resource.

3) I'd like to have some form of "claiming" packages for analysis and
upload, as a form of advisory locking.  However, I see the same thing
effectively happening with ITPs, and people don't get around to it and there
are a zillion old ITPs sitting around.  On the other hand, if I've spent X
hours analysing this software to have someone else upload, it's not going to
be pretty.  Maybe ensuring that the "culture" of this sponsorship system
doesn't make uploading on someone else's old lock the 8th deadly sin will
help.  <shrug>

4) Automatically removing packages once they've been uploaded seems to be a
general winner.  Whether I handle that with a separate upload queue which
analyses and forwards built packages, or just something that watches
-changes and puts a line in them, I'm still undecided.  You'll get better
statefulness just watching -changes, which is why I'm leaning that way. 
But the separate queue just sounds cool.  <g>

Keep suggesting stuff here.  My plan is already about 3 times better than
when I first posted, so this has been a very productive thread so far. 
Thanks to everyone who's responded, both publically and privately.

- Matt



Reply to: