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
