Re: Multi-person sponsorship
Goswin von Brederlow wrote: Now, does the autobuilder get moved to another machine, or do I just put on my scary face when adding people to the authorised uploaders list? grin If you are using i386: umlbuilder That way you need an uml exploit and a root exploit to use the uml exploit. Before you bet too much money on it: I had pbuilder-uml fail on me consistantly for a package where pbuilder worked fine. (The package was a CVS snapshot of (a development version of) libopenhbci, I didn't try the package currently in Debian, thought.) That package died in the middle of a compiler call. Unfortunately, I never got around to investigating whether it was an obvious misconfiguration or somesuch, so I didn't file a bug. Kind regards Thomas -- Thomas Viehmann, http://beamnet.de/tv/ pgp0.pgp Description: PGP signature
Re: Multi-person sponsorship
Goswin von Brederlow wrote: Now, does the autobuilder get moved to another machine, or do I just put on my scary face when adding people to the authorised uploaders list? grin If you are using i386: umlbuilder That way you need an uml exploit and a root exploit to use the uml exploit. Before you bet too much money on it: I had pbuilder-uml fail on me consistantly for a package where pbuilder worked fine. (The package was a CVS snapshot of (a development version of) libopenhbci, I didn't try the package currently in Debian, thought.) That package died in the middle of a compiler call. Unfortunately, I never got around to investigating whether it was an obvious misconfiguration or somesuch, so I didn't file a bug. Kind regards Thomas -- Thomas Viehmann, http://beamnet.de/tv/ pgpK9gArMqA3g.pgp Description: PGP signature
Re: Multi-person sponsorship
On Wed, Feb 18, 2004 at 10:08:34AM +, Thomas Viehmann wrote: Matthew Palmer ([EMAIL PROTECTED]) wrote: 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. Maybe you could talk to the m.d.n guys about integrating download counters and than just use their repository. (After all, all you need is a ssh key.) I was actually hoping that I'd get someone from m.d.n in the thread, but perhaps they don't read d-mentors. I'll probably contact them privately in that case (although if you're reading, feel free to pipe up). 3) I'd like to have some form of claiming packages for analysis and Maybe you could just tag a date of claim on it. (Or maybe even just expire automacially after - say - 10 days.) Timestamping was already on the cards, not sure whether to expire or not, though. 4) Automatically removing packages once they've been uploaded seems to be a general winner. Couldn't you just reference packages.d.o (or a local Packages/Sources file)? Sorry, I don't understand this. Are you suggesting that I scan an updated Packages file for package versions, and if they've got appropriate versions, remove them from the packages to sponsor list? It'll probably be more timely and less bandwidth intensive to track -changes... Maybe you could also reuse / build upon rene from the dak suite. (Maybe it's not That's the problem with the FTP masters naming everything after women - nobody else has the slightest idea of what does what... Certainly seems to have the right idea, although I'm not planning on running an RDBMS to manage this thing any time soon. Thanks for the pointer though, I'm sure I'll be able to pinch some ideas from there. And I didn't know that auric had been reopened, and had a copy of ftp-master, so I'm learning stuff left and right here today. g Also, maybe it's worth talking to mentors.d.n about it. After all, they're probably (interested in) doing this, too. See comments above. g - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
Matthew Palmer ([EMAIL PROTECTED]) wrote: 4) Automatically removing packages once they've been uploaded seems to be a general winner. Couldn't you just reference packages.d.o (or a local Packages/Sources file)? Sorry, I don't understand this. Are you suggesting that I scan an updated Packages file for package versions, and if they've got appropriate versions, remove them from the packages to sponsor list? Yes. Actually the other way round, looking for a version for each package in the sponsorship system... It'll probably be more timely and less bandwidth intensive to track -changes... Well, I mostly have Packages/Sources for unstable available. In my book, I prefer parsing those over automatically processing email. Also, it doesn't matter if you miss a batch of stuff or things like this. Kind regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
On Thu, Feb 19, 2004 at 06:42:42PM +1100, Matthew Palmer wrote: On Wed, Feb 18, 2004 at 10:08:34AM +, Thomas Viehmann wrote: Maybe you could also reuse / build upon rene from the dak suite. (Maybe it's not That's the problem with the FTP masters naming everything after women - nobody else has the slightest idea of what does what... In case you haven't seen it: http://cvs.debian.org/dak/docs/README.names?cvsroot=dak -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
On Thu, Feb 19, 2004 at 08:23:05AM +, Thomas Viehmann wrote: It'll probably be more timely and less bandwidth intensive to track -changes... Well, I mostly have Packages/Sources for unstable available. In my book, I prefer parsing those over automatically processing email. Also, it doesn't matter if you miss a batch of stuff or things like this. The timeliness issue still lurks, though. If I update Packages daily, that's up to 24 hours when a package is in that it's being advertised as not being in. Tracking -changes gets things more quickly (although there is, I guess, the issue of NEW uploads, which are going to suck either way). - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
On Thu, Feb 19, 2004 at 09:39:31AM +, Colin Watson wrote: On Thu, Feb 19, 2004 at 06:42:42PM +1100, Matthew Palmer wrote: On Wed, Feb 18, 2004 at 10:08:34AM +, Thomas Viehmann wrote: Maybe you could also reuse / build upon rene from the dak suite. (Maybe it's not That's the problem with the FTP masters naming everything after women - nobody else has the slightest idea of what does what... In case you haven't seen it: http://cvs.debian.org/dak/docs/README.names?cvsroot=dak I hadn't, and thanks for the pointer. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
Matthew Palmer [EMAIL PROTECTED] writes: On Tue, Feb 17, 2004 at 11:21:11PM -0500, Joey Hess wrote: Matthew Palmer wrote: So, comments, brickbats, acclaim, whatever. Throw it at me. Well I don't think that this system as described would be of any use to me. I want to maintain a close relationship with the people whose A worthy sentiment. I certainly have no wish to tell anyone else how to run sponsorships (especially since I'm not the most experienced sponsor around). However, there's nothing to stop you only checking and uploading packages created by someone you have otherwise agreed to sponsor. Nothing I'm creating is supposed to place an obligation on *anyone* to sponsor something they don't want to - and I apologise if anything I've said gave anyone that impression. I saw this proposal more for people that don't have a sponsor yet. Currently one asks for one and maybe gets one or not. Packages are forgotten or overlooked easily. New packages could be entered into the system and once a sponsor is found asking him for the next upload could be proper practice. There could still be the possibility to use the autobuilder. Packages could get associated with their last sponsor and immediatly marked as taken by XYZ for a week or a month. If the sponsor is on vacation or or gone MIA the package would return to the normal pool for everyone to pick after that week or month. Seeing that new and sponsored packages fail with missing Build-Depends I think having an independent and properly working autobuilder compile each upload as check is a good idea. Too many DDs don't seem to be using pbuilder / umlbuilder / sbuild for a final test. package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be Since you only get packages for sponsorship which have built in a clean sid chroot out of my system, you can be fairly sure of that. ... Also, if things should go wrong, and my sponsee turns out to not have the skills, interest, or time, I consider it my responsibility as the sponsor to do any cleanup that might be required, orphaning or temporarily maintaining packages, etc. That is, IMVHO, an important role for a sponsor. A comment someone made up-thread (about an NM keyring) triggered a thought for me - a kind of sponsee-db.debian.org, where people who are not DDs, but who have sponsored packages, have their info. That'd cover keys, name, country, and some echelon info. That's probably not for me to write, but if anyone's interested in a project, I know that I, for one, would be happier with a wider knowledge of sponsored package maintainers. Each participating NM could get a comments page where hopefully friendly and civilized commends can be posted by sponsors. (I also hope that nobody roots your autobuilder.) That we hope for all the autobuilders. - Matt MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
Matthew Palmer [EMAIL PROTECTED] writes: On Thu, Feb 19, 2004 at 08:23:05AM +, Thomas Viehmann wrote: It'll probably be more timely and less bandwidth intensive to track -changes... Well, I mostly have Packages/Sources for unstable available. In my book, I prefer parsing those over automatically processing email. Also, it doesn't matter if you miss a batch of stuff or things like this. The timeliness issue still lurks, though. If I update Packages daily, that's up to 24 hours when a package is in that it's being advertised as not being in. Tracking -changes gets things more quickly (although there is, I guess, the issue of NEW uploads, which are going to suck either way). - Matt Get access to accepted/autobuild, like the buildds and wanna-build have. Combining that with the main archives packages file you get an hourly update of what will go ino debian or already is. As advantage of that i see: 1. for each package on your list you run grep-dctrl over the packages file, trivial to script and to parse. 2. if something goes wrong and a package is missed the next scan will show it. A lost or missparsed changes mail would need manual intervention. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
Matthew Palmer wrote: package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be Since you only get packages for sponsorship which have built in a clean sid chroot out of my system, you can be fairly sure of that. As you've described the system, it sounds like my sponsee could make several iterations with bad unbuildable packages before it is ever made aailable to me to look at. This is what I want to avoid; if they are not competant to upload a buildable package the first time, I want to know that. I'm interested in how many of your sponsees do you know are/aren't doing, say, QA work quietly, or working on d-i, or doing bug triage? I know that at least one person I'm sponsoring isn't doing anything on anything else, because I used to work with him, but apart from that, the people whose packages I've sponsored could be working towards becoming DPL and I'd hardly know. Should I know these things? Do you think that a good sponsor should be doing these things, or that it's useful in the general case for a sponsor to know all of a sponsees other activities? I use filtering and scoring to keep track of such things reasonably well. Unless they're sending patches to maintainers via private email or something, I am likely to see anything they do in debian. Evenually, and most importantly, if they turn out to be doing a good job, I want to get them into Debian as a proper DD, and that is why I require the numerous bits of information I gather in passing while sponsoring them, so I can know if I want to advocate them or not. If you don't mind me asking, what sort of information do you ask for from potential sponsees? (Warning: your answer may become FAQ fodder g). Info similar to what gets asked for in the background section of NM? I don't ask a set series of questions, I simply get to know the person by working with them, same as I'd get to know any other DD, and reach my own conclusions from that. (I'd also like to see AM's making more use of this information. If I've advocated someone, I can tell you what parts of TS they have already, IMHO, passed.) If you put that information into an advocacy report, does the AM ignore it, or are they not supposed to take other people's experiences into account? (That seems odd, considering that some NMs get their AMs switched on them). I didn't know we had avocacy reports, doesn't the current system only let you enter their email address? (I also hope that nobody roots your autobuilder.) I'm not keen on ever providing the .debs that come out of the autobuilder. Beside the point. Inside the autobuilder, you are running possibly untrusted code. It's only a local exploit away from running as root, at which time it can easily break out of any chroot you have it in. If it's in an UML jail it also has to exploit a hole in the linux kernel, but we have no shortage of those. :-/ -- see shy jo signature.asc Description: Digital signature
Re: Multi-person sponsorship
On Thu, Feb 19, 2004 at 01:05:08PM -0500, Joey Hess wrote: Matthew Palmer wrote: package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be Since you only get packages for sponsorship which have built in a clean sid chroot out of my system, you can be fairly sure of that. As you've described the system, it sounds like my sponsee could make several iterations with bad unbuildable packages before it is ever made aailable to me to look at. This is what I want to avoid; if they are not competant to upload a buildable package the first time, I want to know that. Noted. An upload history per-person would address that point to some degree. I'm interested in how many of your sponsees do you know are/aren't doing, say, QA work quietly, or working on d-i, or doing bug triage? I know that at least one person I'm sponsoring isn't doing anything on anything else, because I used to work with him, but apart from that, the people whose packages I've sponsored could be working towards becoming DPL and I'd hardly know. Should I know these things? Do you think that a good sponsor should be doing these things, or that it's useful in the general case for a sponsor to know all of a sponsees other activities? I use filtering and scoring to keep track of such things reasonably well. Unless they're sending patches to maintainers via private email or something, I am likely to see anything they do in debian. Do you think that is a recommended activity for sponsors in general, or do you do it more for personal curiousity? (I'd also like to see AM's making more use of this information. If I've advocated someone, I can tell you what parts of TS they have already, IMHO, passed.) If you put that information into an advocacy report, does the AM ignore it, or are they not supposed to take other people's experiences into account? (That seems odd, considering that some NMs get their AMs switched on them). I didn't know we had avocacy reports, doesn't the current system only let you enter their email address? From memory (and this may have changed subsequently), after you say yes I want to advocate this NM candidate, you get an e-mail saying please fill in here why you advocate this person, and send it GPG signed back to us. I presume the comments in there would go into the NM's file. (I also hope that nobody roots your autobuilder.) I'm not keen on ever providing the .debs that come out of the autobuilder. Beside the point. Inside the autobuilder, you are running possibly untrusted code. It's only a local exploit away from running as root, at Yes, I did miss your point. Thank you for pointing it out. Now, does the autobuilder get moved to another machine, or do I just put on my scary face when adding people to the authorised uploaders list? grin - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
Matthew Palmer [EMAIL PROTECTED] writes: On Thu, Feb 19, 2004 at 01:05:08PM -0500, Joey Hess wrote: Matthew Palmer wrote: package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be Since you only get packages for sponsorship which have built in a clean sid chroot out of my system, you can be fairly sure of that. As you've described the system, it sounds like my sponsee could make several iterations with bad unbuildable packages before it is ever made aailable to me to look at. This is what I want to avoid; if they are not competant to upload a buildable package the first time, I want to know that. Noted. An upload history per-person would address that point to some degree. Just keep the buildd logs. I'm interested in how many of your sponsees do you know are/aren't doing, say, QA work quietly, or working on d-i, or doing bug triage? I know that at least one person I'm sponsoring isn't doing anything on anything else, because I used to work with him, but apart from that, the people whose packages I've sponsored could be working towards becoming DPL and I'd hardly know. Should I know these things? Do you think that a good sponsor should be doing these things, or that it's useful in the general case for a sponsor to know all of a sponsees other activities? I use filtering and scoring to keep track of such things reasonably well. Unless they're sending patches to maintainers via private email or something, I am likely to see anything they do in debian. Do you think that is a recommended activity for sponsors in general, or do you do it more for personal curiousity? (I'd also like to see AM's making more use of this information. If I've advocated someone, I can tell you what parts of TS they have already, IMHO, passed.) If you put that information into an advocacy report, does the AM ignore it, or are they not supposed to take other people's experiences into account? (That seems odd, considering that some NMs get their AMs switched on them). I didn't know we had avocacy reports, doesn't the current system only let you enter their email address? From memory (and this may have changed subsequently), after you say yes I want to advocate this NM candidate, you get an e-mail saying please fill in here why you advocate this person, and send it GPG signed back to us. I presume the comments in there would go into the NM's file. (I also hope that nobody roots your autobuilder.) I'm not keen on ever providing the .debs that come out of the autobuilder. Beside the point. Inside the autobuilder, you are running possibly untrusted code. It's only a local exploit away from running as root, at Yes, I did miss your point. Thank you for pointing it out. Now, does the autobuilder get moved to another machine, or do I just put on my scary face when adding people to the authorised uploaders list? grin If you are using i386: umlbuilder That way you need an uml exploit and a root exploit to use the uml exploit. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
On Tue, Feb 17, 2004 at 11:21:11PM -0500, Joey Hess wrote: Matthew Palmer wrote: So, comments, brickbats, acclaim, whatever. Throw it at me. Well I don't think that this system as described would be of any use to me. I want to maintain a close relationship with the people whose A worthy sentiment. I certainly have no wish to tell anyone else how to run sponsorships (especially since I'm not the most experienced sponsor around). However, there's nothing to stop you only checking and uploading packages created by someone you have otherwise agreed to sponsor. Nothing I'm creating is supposed to place an obligation on *anyone* to sponsor something they don't want to - and I apologise if anything I've said gave anyone that impression. package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be Since you only get packages for sponsorship which have built in a clean sid chroot out of my system, you can be fairly sure of that. familiar with the overall work they are doing on Debian, so I want to always sponsor their package except when I'm unavailable (or too slow). That's likely to be the biggest problem, when you want to be maintainer for a maintainer. grin However, you can easily just pick out the packages of people you want to sponsor, and leave the rest. The benefit of my system is that you've got something of a todo list (a la qa.d.o/maintainer.php) of outstanding sponsorships. You never know, you might see someone new there are decide to contact them and sponsor them... I'm interested in how many of your sponsees do you know are/aren't doing, say, QA work quietly, or working on d-i, or doing bug triage? I know that at least one person I'm sponsoring isn't doing anything on anything else, because I used to work with him, but apart from that, the people whose packages I've sponsored could be working towards becoming DPL and I'd hardly know. Should I know these things? Do you think that a good sponsor should be doing these things, or that it's useful in the general case for a sponsor to know all of a sponsees other activities? (Those are serious questions, BTW, although on reading back they might sound argumentative) Evenually, and most importantly, if they turn out to be doing a good job, I want to get them into Debian as a proper DD, and that is why I require the numerous bits of information I gather in passing while sponsoring them, so I can know if I want to advocate them or not. If you don't mind me asking, what sort of information do you ask for from potential sponsees? (Warning: your answer may become FAQ fodder g). Info similar to what gets asked for in the background section of NM? (I'd also like to see AM's making more use of this information. If I've advocated someone, I can tell you what parts of TS they have already, IMHO, passed.) If you put that information into an advocacy report, does the AM ignore it, or are they not supposed to take other people's experiences into account? (That seems odd, considering that some NMs get their AMs switched on them). Also, if things should go wrong, and my sponsee turns out to not have the skills, interest, or time, I consider it my responsibility as the sponsor to do any cleanup that might be required, orphaning or temporarily maintaining packages, etc. That is, IMVHO, an important role for a sponsor. A comment someone made up-thread (about an NM keyring) triggered a thought for me - a kind of sponsee-db.debian.org, where people who are not DDs, but who have sponsored packages, have their info. That'd cover keys, name, country, and some echelon info. That's probably not for me to write, but if anyone's interested in a project, I know that I, for one, would be happier with a wider knowledge of sponsored package maintainers. I don't see that your system helps with any of these things. I can see it being possibly useful in the case where I am temporarily unavailable and my sponsee needs to make an upload, but I cannot imagine myself using it to randomly request to perform such a sponsorship for someone I don't know and don't have a working relationship with, for a package with which I am unfamiliar. As I said at the beginning of this message (and which I think bears repeating), I'm not interested in making this the one true sponsorship way, nor do I want anyone to think that they have to sponsor whatever's next in the queue. Just me, perhaps. No, your comments have, for the most part, echoed my own sentiments, and embodied them far more eloquently than I could have done. Thanks for taking the time to write them down. (I also hope that nobody roots your autobuilder.) I'm not keen on ever providing the .debs that come out of the autobuilder. It's a does this build? here's the build and lintian logs from the build, showing what happened test only. For upload purposes, I expect sponsors to check, build, and upload from the
Re: Multi-person sponsorship
On Wed, Feb 18, 2004 at 10:08:34AM +, Thomas Viehmann wrote: Matthew Palmer ([EMAIL PROTECTED]) wrote: 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. Maybe you could talk to the m.d.n guys about integrating download counters and than just use their repository. (After all, all you need is a ssh key.) I was actually hoping that I'd get someone from m.d.n in the thread, but perhaps they don't read d-mentors. I'll probably contact them privately in that case (although if you're reading, feel free to pipe up). 3) I'd like to have some form of claiming packages for analysis and Maybe you could just tag a date of claim on it. (Or maybe even just expire automacially after - say - 10 days.) Timestamping was already on the cards, not sure whether to expire or not, though. 4) Automatically removing packages once they've been uploaded seems to be a general winner. Couldn't you just reference packages.d.o (or a local Packages/Sources file)? Sorry, I don't understand this. Are you suggesting that I scan an updated Packages file for package versions, and if they've got appropriate versions, remove them from the packages to sponsor list? It'll probably be more timely and less bandwidth intensive to track -changes... Maybe you could also reuse / build upon rene from the dak suite. (Maybe it's not That's the problem with the FTP masters naming everything after women - nobody else has the slightest idea of what does what... Certainly seems to have the right idea, although I'm not planning on running an RDBMS to manage this thing any time soon. Thanks for the pointer though, I'm sure I'll be able to pinch some ideas from there. And I didn't know that auric had been reopened, and had a copy of ftp-master, so I'm learning stuff left and right here today. g Also, maybe it's worth talking to mentors.d.n about it. After all, they're probably (interested in) doing this, too. See comments above. g - Matt
Re: Multi-person sponsorship
Matthew Palmer ([EMAIL PROTECTED]) wrote: 4) Automatically removing packages once they've been uploaded seems to be a general winner. Couldn't you just reference packages.d.o (or a local Packages/Sources file)? Sorry, I don't understand this. Are you suggesting that I scan an updated Packages file for package versions, and if they've got appropriate versions, remove them from the packages to sponsor list? Yes. Actually the other way round, looking for a version for each package in the sponsorship system... It'll probably be more timely and less bandwidth intensive to track -changes... Well, I mostly have Packages/Sources for unstable available. In my book, I prefer parsing those over automatically processing email. Also, it doesn't matter if you miss a batch of stuff or things like this. Kind regards Thomas
Re: Multi-person sponsorship
On Thu, Feb 19, 2004 at 06:42:42PM +1100, Matthew Palmer wrote: On Wed, Feb 18, 2004 at 10:08:34AM +, Thomas Viehmann wrote: Maybe you could also reuse / build upon rene from the dak suite. (Maybe it's not That's the problem with the FTP masters naming everything after women - nobody else has the slightest idea of what does what... In case you haven't seen it: http://cvs.debian.org/dak/docs/README.names?cvsroot=dak -- Colin Watson [EMAIL PROTECTED]
Re: Multi-person sponsorship
On Thu, Feb 19, 2004 at 08:23:05AM +, Thomas Viehmann wrote: It'll probably be more timely and less bandwidth intensive to track -changes... Well, I mostly have Packages/Sources for unstable available. In my book, I prefer parsing those over automatically processing email. Also, it doesn't matter if you miss a batch of stuff or things like this. The timeliness issue still lurks, though. If I update Packages daily, that's up to 24 hours when a package is in that it's being advertised as not being in. Tracking -changes gets things more quickly (although there is, I guess, the issue of NEW uploads, which are going to suck either way). - Matt
Re: Multi-person sponsorship
On Thu, Feb 19, 2004 at 09:39:31AM +, Colin Watson wrote: On Thu, Feb 19, 2004 at 06:42:42PM +1100, Matthew Palmer wrote: On Wed, Feb 18, 2004 at 10:08:34AM +, Thomas Viehmann wrote: Maybe you could also reuse / build upon rene from the dak suite. (Maybe it's not That's the problem with the FTP masters naming everything after women - nobody else has the slightest idea of what does what... In case you haven't seen it: http://cvs.debian.org/dak/docs/README.names?cvsroot=dak I hadn't, and thanks for the pointer. - Matt
Re: Multi-person sponsorship
Matthew Palmer [EMAIL PROTECTED] writes: On Thu, Feb 19, 2004 at 08:23:05AM +, Thomas Viehmann wrote: It'll probably be more timely and less bandwidth intensive to track -changes... Well, I mostly have Packages/Sources for unstable available. In my book, I prefer parsing those over automatically processing email. Also, it doesn't matter if you miss a batch of stuff or things like this. The timeliness issue still lurks, though. If I update Packages daily, that's up to 24 hours when a package is in that it's being advertised as not being in. Tracking -changes gets things more quickly (although there is, I guess, the issue of NEW uploads, which are going to suck either way). - Matt Get access to accepted/autobuild, like the buildds and wanna-build have. Combining that with the main archives packages file you get an hourly update of what will go ino debian or already is. As advantage of that i see: 1. for each package on your list you run grep-dctrl over the packages file, trivial to script and to parse. 2. if something goes wrong and a package is missed the next scan will show it. A lost or missparsed changes mail would need manual intervention. MfG Goswin
Re: Multi-person sponsorship
Matthew Palmer [EMAIL PROTECTED] writes: On Tue, Feb 17, 2004 at 11:21:11PM -0500, Joey Hess wrote: Matthew Palmer wrote: So, comments, brickbats, acclaim, whatever. Throw it at me. Well I don't think that this system as described would be of any use to me. I want to maintain a close relationship with the people whose A worthy sentiment. I certainly have no wish to tell anyone else how to run sponsorships (especially since I'm not the most experienced sponsor around). However, there's nothing to stop you only checking and uploading packages created by someone you have otherwise agreed to sponsor. Nothing I'm creating is supposed to place an obligation on *anyone* to sponsor something they don't want to - and I apologise if anything I've said gave anyone that impression. I saw this proposal more for people that don't have a sponsor yet. Currently one asks for one and maybe gets one or not. Packages are forgotten or overlooked easily. New packages could be entered into the system and once a sponsor is found asking him for the next upload could be proper practice. There could still be the possibility to use the autobuilder. Packages could get associated with their last sponsor and immediatly marked as taken by XYZ for a week or a month. If the sponsor is on vacation or or gone MIA the package would return to the normal pool for everyone to pick after that week or month. Seeing that new and sponsored packages fail with missing Build-Depends I think having an independent and properly working autobuilder compile each upload as check is a good idea. Too many DDs don't seem to be using pbuilder / umlbuilder / sbuild for a final test. package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be Since you only get packages for sponsorship which have built in a clean sid chroot out of my system, you can be fairly sure of that. ... Also, if things should go wrong, and my sponsee turns out to not have the skills, interest, or time, I consider it my responsibility as the sponsor to do any cleanup that might be required, orphaning or temporarily maintaining packages, etc. That is, IMVHO, an important role for a sponsor. A comment someone made up-thread (about an NM keyring) triggered a thought for me - a kind of sponsee-db.debian.org, where people who are not DDs, but who have sponsored packages, have their info. That'd cover keys, name, country, and some echelon info. That's probably not for me to write, but if anyone's interested in a project, I know that I, for one, would be happier with a wider knowledge of sponsored package maintainers. Each participating NM could get a comments page where hopefully friendly and civilized commends can be posted by sponsors. (I also hope that nobody roots your autobuilder.) That we hope for all the autobuilders. - Matt MfG Goswin
Re: Multi-person sponsorship
Matthew Palmer wrote: package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be Since you only get packages for sponsorship which have built in a clean sid chroot out of my system, you can be fairly sure of that. As you've described the system, it sounds like my sponsee could make several iterations with bad unbuildable packages before it is ever made aailable to me to look at. This is what I want to avoid; if they are not competant to upload a buildable package the first time, I want to know that. I'm interested in how many of your sponsees do you know are/aren't doing, say, QA work quietly, or working on d-i, or doing bug triage? I know that at least one person I'm sponsoring isn't doing anything on anything else, because I used to work with him, but apart from that, the people whose packages I've sponsored could be working towards becoming DPL and I'd hardly know. Should I know these things? Do you think that a good sponsor should be doing these things, or that it's useful in the general case for a sponsor to know all of a sponsees other activities? I use filtering and scoring to keep track of such things reasonably well. Unless they're sending patches to maintainers via private email or something, I am likely to see anything they do in debian. Evenually, and most importantly, if they turn out to be doing a good job, I want to get them into Debian as a proper DD, and that is why I require the numerous bits of information I gather in passing while sponsoring them, so I can know if I want to advocate them or not. If you don't mind me asking, what sort of information do you ask for from potential sponsees? (Warning: your answer may become FAQ fodder g). Info similar to what gets asked for in the background section of NM? I don't ask a set series of questions, I simply get to know the person by working with them, same as I'd get to know any other DD, and reach my own conclusions from that. (I'd also like to see AM's making more use of this information. If I've advocated someone, I can tell you what parts of TS they have already, IMHO, passed.) If you put that information into an advocacy report, does the AM ignore it, or are they not supposed to take other people's experiences into account? (That seems odd, considering that some NMs get their AMs switched on them). I didn't know we had avocacy reports, doesn't the current system only let you enter their email address? (I also hope that nobody roots your autobuilder.) I'm not keen on ever providing the .debs that come out of the autobuilder. Beside the point. Inside the autobuilder, you are running possibly untrusted code. It's only a local exploit away from running as root, at which time it can easily break out of any chroot you have it in. If it's in an UML jail it also has to exploit a hole in the linux kernel, but we have no shortage of those. :-/ -- see shy jo signature.asc Description: Digital signature
Re: Multi-person sponsorship
On Thu, Feb 19, 2004 at 01:05:08PM -0500, Joey Hess wrote: Matthew Palmer wrote: package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be Since you only get packages for sponsorship which have built in a clean sid chroot out of my system, you can be fairly sure of that. As you've described the system, it sounds like my sponsee could make several iterations with bad unbuildable packages before it is ever made aailable to me to look at. This is what I want to avoid; if they are not competant to upload a buildable package the first time, I want to know that. Noted. An upload history per-person would address that point to some degree. I'm interested in how many of your sponsees do you know are/aren't doing, say, QA work quietly, or working on d-i, or doing bug triage? I know that at least one person I'm sponsoring isn't doing anything on anything else, because I used to work with him, but apart from that, the people whose packages I've sponsored could be working towards becoming DPL and I'd hardly know. Should I know these things? Do you think that a good sponsor should be doing these things, or that it's useful in the general case for a sponsor to know all of a sponsees other activities? I use filtering and scoring to keep track of such things reasonably well. Unless they're sending patches to maintainers via private email or something, I am likely to see anything they do in debian. Do you think that is a recommended activity for sponsors in general, or do you do it more for personal curiousity? (I'd also like to see AM's making more use of this information. If I've advocated someone, I can tell you what parts of TS they have already, IMHO, passed.) If you put that information into an advocacy report, does the AM ignore it, or are they not supposed to take other people's experiences into account? (That seems odd, considering that some NMs get their AMs switched on them). I didn't know we had avocacy reports, doesn't the current system only let you enter their email address? From memory (and this may have changed subsequently), after you say yes I want to advocate this NM candidate, you get an e-mail saying please fill in here why you advocate this person, and send it GPG signed back to us. I presume the comments in there would go into the NM's file. (I also hope that nobody roots your autobuilder.) I'm not keen on ever providing the .debs that come out of the autobuilder. Beside the point. Inside the autobuilder, you are running possibly untrusted code. It's only a local exploit away from running as root, at Yes, I did miss your point. Thank you for pointing it out. Now, does the autobuilder get moved to another machine, or do I just put on my scary face when adding people to the authorised uploaders list? grin - Matt
Re: Multi-person sponsorship
Matthew Palmer [EMAIL PROTECTED] writes: On Thu, Feb 19, 2004 at 01:05:08PM -0500, Joey Hess wrote: Matthew Palmer wrote: package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be Since you only get packages for sponsorship which have built in a clean sid chroot out of my system, you can be fairly sure of that. As you've described the system, it sounds like my sponsee could make several iterations with bad unbuildable packages before it is ever made aailable to me to look at. This is what I want to avoid; if they are not competant to upload a buildable package the first time, I want to know that. Noted. An upload history per-person would address that point to some degree. Just keep the buildd logs. I'm interested in how many of your sponsees do you know are/aren't doing, say, QA work quietly, or working on d-i, or doing bug triage? I know that at least one person I'm sponsoring isn't doing anything on anything else, because I used to work with him, but apart from that, the people whose packages I've sponsored could be working towards becoming DPL and I'd hardly know. Should I know these things? Do you think that a good sponsor should be doing these things, or that it's useful in the general case for a sponsor to know all of a sponsees other activities? I use filtering and scoring to keep track of such things reasonably well. Unless they're sending patches to maintainers via private email or something, I am likely to see anything they do in debian. Do you think that is a recommended activity for sponsors in general, or do you do it more for personal curiousity? (I'd also like to see AM's making more use of this information. If I've advocated someone, I can tell you what parts of TS they have already, IMHO, passed.) If you put that information into an advocacy report, does the AM ignore it, or are they not supposed to take other people's experiences into account? (That seems odd, considering that some NMs get their AMs switched on them). I didn't know we had avocacy reports, doesn't the current system only let you enter their email address? From memory (and this may have changed subsequently), after you say yes I want to advocate this NM candidate, you get an e-mail saying please fill in here why you advocate this person, and send it GPG signed back to us. I presume the comments in there would go into the NM's file. (I also hope that nobody roots your autobuilder.) I'm not keen on ever providing the .debs that come out of the autobuilder. Beside the point. Inside the autobuilder, you are running possibly untrusted code. It's only a local exploit away from running as root, at Yes, I did miss your point. Thank you for pointing it out. Now, does the autobuilder get moved to another machine, or do I just put on my scary face when adding people to the authorised uploaders list? grin If you are using i386: umlbuilder That way you need an uml exploit and a root exploit to use the uml exploit. MfG Goswin
Re: Multi-person sponsorship
On Tuesday 17 February 2004 19.52, Thomas Viehmann wrote: Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? This could be done completely automatically. There are many people who got a signature by a DD's key who are not applying for DDship, probably never will, and who probably should not be able to upload to your queue. Getting a signature is just a confirmation of identity, after all. cheers -- vbi -- featured link: http://www.pool.ntp.org pgp0.pgp Description: signature
Re: Multi-person sponsorship
Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: There are many people who got a signature by a DD's key who are not applying for DDship, probably never will, and who probably should not be able to upload to your queue. Getting a signature is just a confirmation of identity, after all. Well, those won't learn to prepare packages and upload them just to irritate someone, will they? If you'd want to, you could put in an additional check for either - a corresponding ITP/RFA, or - a package already maintained by the uploader, and otherwise fall back go to more manual processing. Cheers T. -- Thomas Viehmann, http://beamnet.de/tv/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
On Wed, Feb 18, 2004 at 10:22:22AM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: On Tuesday 17 February 2004 19.52, Thomas Viehmann wrote: Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? This could be done completely automatically. There are many people who got a signature by a DD's key who are not applying for DDship, probably never will, and who probably should not be able to upload to your queue. Getting a signature is just a confirmation of identity, after all. Yeah, I'm not overly keen on the idea of automatically allowing anyone signed by a DD to upload, but since a DD should be checking the upload anyway, the problem isn't as nasty as it might seem. I'm leaning towards the idea of a sponsee keyring, containing NMs and potential NMs. The only requirement would be a stated desire to be a maintainer and some sort of trust link into Debian (direct signature probably not required). Ideally, that'd eventually become a your key must be in here to be a sponsored maintainer requirement, but that is *so* *far* beyond what I've get any hope in hell of mandating, I'm not going within a million miles of that. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
Hi. Matthew Palmer ([EMAIL PROTECTED]) wrote: 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. Maybe you could talk to the m.d.n guys about integrating download counters and than just use their repository. (After all, all you need is a ssh key.) 3) I'd like to have some form of claiming packages for analysis and Maybe you could just tag a date of claim on it. (Or maybe even just expire automacially after - say - 10 days.) 4) Automatically removing packages once they've been uploaded seems to be a general winner. Couldn't you just reference packages.d.o (or a local Packages/Sources file)? Maybe you could also reuse / build upon rene from the dak suite. (Maybe it's not worth the trouble.) Probably packages could be expired by timeout as well. Also, maybe it's worth talking to mentors.d.n about it. After all, they're probably (interested in) doing this, too. Cheers T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
Matthew Palmer wrote: So, comments, brickbats, acclaim, whatever. Throw it at me. Well I don't think that this system as described would be of any use to me. I want to maintain a close relationship with the people whose package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be familiar with the overall work they are doing on Debian, so I want to always sponsor their package except when I'm unavailable (or too slow). Evenually, and most importantly, if they turn out to be doing a good job, I want to get them into Debian as a proper DD, and that is why I require the numerous bits of information I gather in passing while sponsoring them, so I can know if I want to advocate them or not. (I'd also like to see AM's making more use of this information. If I've advocated someone, I can tell you what parts of TS they have already, IMHO, passed.) Also, if things should go wrong, and my sponsee turns out to not have the skills, interest, or time, I consider it my responsibility as the sponsor to do any cleanup that might be required, orphaning or temporarily maintaining packages, etc. I don't see that your system helps with any of these things. I can see it being possibly useful in the case where I am temporarily unavailable and my sponsee needs to make an upload, but I cannot imagine myself using it to randomly request to perform such a sponsorship for someone I don't know and don't have a working relationship with, for a package with which I am unfamiliar. Just me, perhaps. (I also hope that nobody roots your autobuilder.) -- see shy jo signature.asc Description: Digital signature
Re: Multi-person sponsorship
On Tue, Feb 17, 2004 at 11:21:11PM -0500, Joey Hess wrote: Matthew Palmer wrote: So, comments, brickbats, acclaim, whatever. Throw it at me. Well I don't think that this system as described would be of any use to me. I want to maintain a close relationship with the people whose A worthy sentiment. I certainly have no wish to tell anyone else how to run sponsorships (especially since I'm not the most experienced sponsor around). However, there's nothing to stop you only checking and uploading packages created by someone you have otherwise agreed to sponsor. Nothing I'm creating is supposed to place an obligation on *anyone* to sponsor something they don't want to - and I apologise if anything I've said gave anyone that impression. package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be Since you only get packages for sponsorship which have built in a clean sid chroot out of my system, you can be fairly sure of that. familiar with the overall work they are doing on Debian, so I want to always sponsor their package except when I'm unavailable (or too slow). That's likely to be the biggest problem, when you want to be maintainer for a maintainer. grin However, you can easily just pick out the packages of people you want to sponsor, and leave the rest. The benefit of my system is that you've got something of a todo list (a la qa.d.o/maintainer.php) of outstanding sponsorships. You never know, you might see someone new there are decide to contact them and sponsor them... I'm interested in how many of your sponsees do you know are/aren't doing, say, QA work quietly, or working on d-i, or doing bug triage? I know that at least one person I'm sponsoring isn't doing anything on anything else, because I used to work with him, but apart from that, the people whose packages I've sponsored could be working towards becoming DPL and I'd hardly know. Should I know these things? Do you think that a good sponsor should be doing these things, or that it's useful in the general case for a sponsor to know all of a sponsees other activities? (Those are serious questions, BTW, although on reading back they might sound argumentative) Evenually, and most importantly, if they turn out to be doing a good job, I want to get them into Debian as a proper DD, and that is why I require the numerous bits of information I gather in passing while sponsoring them, so I can know if I want to advocate them or not. If you don't mind me asking, what sort of information do you ask for from potential sponsees? (Warning: your answer may become FAQ fodder g). Info similar to what gets asked for in the background section of NM? (I'd also like to see AM's making more use of this information. If I've advocated someone, I can tell you what parts of TS they have already, IMHO, passed.) If you put that information into an advocacy report, does the AM ignore it, or are they not supposed to take other people's experiences into account? (That seems odd, considering that some NMs get their AMs switched on them). Also, if things should go wrong, and my sponsee turns out to not have the skills, interest, or time, I consider it my responsibility as the sponsor to do any cleanup that might be required, orphaning or temporarily maintaining packages, etc. That is, IMVHO, an important role for a sponsor. A comment someone made up-thread (about an NM keyring) triggered a thought for me - a kind of sponsee-db.debian.org, where people who are not DDs, but who have sponsored packages, have their info. That'd cover keys, name, country, and some echelon info. That's probably not for me to write, but if anyone's interested in a project, I know that I, for one, would be happier with a wider knowledge of sponsored package maintainers. I don't see that your system helps with any of these things. I can see it being possibly useful in the case where I am temporarily unavailable and my sponsee needs to make an upload, but I cannot imagine myself using it to randomly request to perform such a sponsorship for someone I don't know and don't have a working relationship with, for a package with which I am unfamiliar. As I said at the beginning of this message (and which I think bears repeating), I'm not interested in making this the one true sponsorship way, nor do I want anyone to think that they have to sponsor whatever's next in the queue. Just me, perhaps. No, your comments have, for the most part, echoed my own sentiments, and embodied them far more eloquently than I could have done. Thanks for taking the time to write them down. (I also hope that nobody roots your autobuilder.) I'm not keen on ever providing the .debs that come out of the autobuilder. It's a does this build? here's the build and lintian logs from the build, showing what happened test only. For upload purposes, I expect sponsors to check, build, and upload from the
Re: Multi-person sponsorship
On Tuesday 17 February 2004 19.52, Thomas Viehmann wrote: Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? This could be done completely automatically. There are many people who got a signature by a DD's key who are not applying for DDship, probably never will, and who probably should not be able to upload to your queue. Getting a signature is just a confirmation of identity, after all. cheers -- vbi -- featured link: http://www.pool.ntp.org pgpFg9MitgWEr.pgp Description: signature
Re: Multi-person sponsorship
Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: There are many people who got a signature by a DD's key who are not applying for DDship, probably never will, and who probably should not be able to upload to your queue. Getting a signature is just a confirmation of identity, after all. Well, those won't learn to prepare packages and upload them just to irritate someone, will they? If you'd want to, you could put in an additional check for either - a corresponding ITP/RFA, or - a package already maintained by the uploader, and otherwise fall back go to more manual processing. Cheers T. -- Thomas Viehmann, http://beamnet.de/tv/
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
Re: Multi-person sponsorship
On Wed, Feb 18, 2004 at 10:22:22AM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: On Tuesday 17 February 2004 19.52, Thomas Viehmann wrote: Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? This could be done completely automatically. There are many people who got a signature by a DD's key who are not applying for DDship, probably never will, and who probably should not be able to upload to your queue. Getting a signature is just a confirmation of identity, after all. Yeah, I'm not overly keen on the idea of automatically allowing anyone signed by a DD to upload, but since a DD should be checking the upload anyway, the problem isn't as nasty as it might seem. I'm leaning towards the idea of a sponsee keyring, containing NMs and potential NMs. The only requirement would be a stated desire to be a maintainer and some sort of trust link into Debian (direct signature probably not required). Ideally, that'd eventually become a your key must be in here to be a sponsored maintainer requirement, but that is *so* *far* beyond what I've get any hope in hell of mandating, I'm not going within a million miles of that. - Matt
Re: Multi-person sponsorship
Hi. Matthew Palmer ([EMAIL PROTECTED]) wrote: 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. Maybe you could talk to the m.d.n guys about integrating download counters and than just use their repository. (After all, all you need is a ssh key.) 3) I'd like to have some form of claiming packages for analysis and Maybe you could just tag a date of claim on it. (Or maybe even just expire automacially after - say - 10 days.) 4) Automatically removing packages once they've been uploaded seems to be a general winner. Couldn't you just reference packages.d.o (or a local Packages/Sources file)? Maybe you could also reuse / build upon rene from the dak suite. (Maybe it's not worth the trouble.) Probably packages could be expired by timeout as well. Also, maybe it's worth talking to mentors.d.n about it. After all, they're probably (interested in) doing this, too. Cheers T.
Re: Multi-person sponsorship
Matthew Palmer wrote: So, comments, brickbats, acclaim, whatever. Throw it at me. Well I don't think that this system as described would be of any use to me. I want to maintain a close relationship with the people whose package I sponsor. I want to know if they are not able to send me a package that will build properly. I want to work with them and be familiar with the overall work they are doing on Debian, so I want to always sponsor their package except when I'm unavailable (or too slow). Evenually, and most importantly, if they turn out to be doing a good job, I want to get them into Debian as a proper DD, and that is why I require the numerous bits of information I gather in passing while sponsoring them, so I can know if I want to advocate them or not. (I'd also like to see AM's making more use of this information. If I've advocated someone, I can tell you what parts of TS they have already, IMHO, passed.) Also, if things should go wrong, and my sponsee turns out to not have the skills, interest, or time, I consider it my responsibility as the sponsor to do any cleanup that might be required, orphaning or temporarily maintaining packages, etc. I don't see that your system helps with any of these things. I can see it being possibly useful in the case where I am temporarily unavailable and my sponsee needs to make an upload, but I cannot imagine myself using it to randomly request to perform such a sponsorship for someone I don't know and don't have a working relationship with, for a package with which I am unfamiliar. Just me, perhaps. (I also hope that nobody roots your autobuilder.) -- see shy jo signature.asc Description: Digital signature
Re: Multi-person sponsorship
On Tue, Feb 17, 2004 at 11:57:55PM +1100, Matthew Palmer 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. 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. 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. 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. -- Jamin W. Collins To be nobody but yourself when the whole world is trying it's best night and day to make you everybody else is to fight the hardest battle any human being will fight. -- E.E. Cummings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
Matthew Palmer [EMAIL PROTECTED] 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.
Re: Multi-person sponsorship
Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? This could be done completely automatically. Cheers T. -- Thomas Viehmann, http://beamnet.de/tv/ pgp0.pgp Description: PGP signature
Re: Multi-person sponsorship
Thomas Viehmann [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? This could be done completely automatically. Cheers T. Because then you would need a DD sponsoring your uploading sources to the sponsoring pool be sponsored by a DD after build. The check is ment for the source so as not to build just anything. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
Goswin von Brederlow wrote: Thomas Viehmann [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? ^^^ the key, not the package This could be done completely automatically. Because then you would need a DD sponsoring your uploading sources to the sponsoring pool be sponsored by a DD after build. The check is ment for the source so as not to build just anything. I'd think you misunderstood me, but it might be vice versa... Cheers T. -- Thomas Viehmann, http://beamnet.de/tv/ pgp0.pgp Description: PGP signature
Re: Multi-person sponsorship
On Tue, Feb 17, 2004 at 07:11:08PM +0100, Goswin von Brederlow wrote: 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? If the .changes isn't signed by a key in the uploaders keyring, it gets rejected. The exact criteria for who gets their key in hasn't been thought about yet - so far, it's been people I intend to sponsor. I presume it'll be something like that in the future, too. I hope you destroy the chroot after each build and unpack it anew. Sing it loud, and sing it clear - We love pbuilder! We love pbuilder! 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. I hadn't thought about an NM keyring, but that has a certain amount of sense to it. I'd like to not limit the sponsorship service to just people who are in the NM queue, but even a sponsee keyring - perhaps separated by NM/non-NM - would be of definite benefit. Knowing the trust path of the maintainer of your software would be useful, even when they're not a DD. 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. I'm not likely to get an S/390 anytime soon (although donations are, of course, more than welcome). g But I'm happy to put multiarch building into the system if you'd be willing to run a buildd for it (I'm depressingly single-arch these days). 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. Hmm, yes. What I've got at the moment is tarballs built from the autobuilder output, with the .dsc, everything mentioned in there, and the build log. My thought was that sponsors, when they wanted to get something to sponsor, would download that tarball (everything you need in one easy package). If you think it would be more helpful, I've already got a package pool set up internally that I can easily convert for the purpose if needed. * 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 I'm wondering if that might be sailing a little close to the wind, though. I'd prefer not to fiddle with the way things are done too much this early, and automating uploads feels a little too much like it's ripe for abuse. At least this way, since it's going to take the sponsor some time just to build the package ready for sign+upload, hopefully they'll spend the extra time looking for problems and maybe trying the package. 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. This isn't a bad idea. I might have to get a little funky with my mod_rewrite skills (pitiful as they are) and get something going so I can do some reference-counting (and general funky stuff). * 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. So I still have to write my MIME-aware mail checker? Bummer. grin * Once selected by a sponsor, a package for sponsorship is taken off
Re: Multi-person sponsorship
Thomas Viehmann [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Thomas Viehmann [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? ^^^ the key, not the package This could be done completely automatically. Because then you would need a DD sponsoring your uploading sources to the sponsoring pool be sponsored by a DD after build. The check is ment for the source so as not to build just anything. I'd think you misunderstood me, but it might be vice versa... Yes, I did. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-person sponsorship
Matthew Palmer [EMAIL PROTECTED] writes: On Tue, Feb 17, 2004 at 07:11:08PM +0100, Goswin von Brederlow wrote: 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? If the .changes isn't signed by a key in the uploaders keyring, it gets rejected. The exact criteria for who gets their key in hasn't been thought about yet - so far, it's been people I intend to sponsor. I presume it'll be something like that in the future, too. That was what I had in mind, just everyone in the sponsoring group, or any DD, should be able to add or remove keys. Or accept any key signed by a DD or something that won#t be as hard as becoming a DD itself. I hope you destroy the chroot after each build and unpack it anew. Sing it loud, and sing it clear - We love pbuilder! We love pbuilder! 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. I hadn't thought about an NM keyring, but that has a certain amount of sense to it. I'd like to not limit the sponsorship service to just people who are in the NM queue, but even a sponsee keyring - perhaps separated by NM/non-NM - would be of definite benefit. Knowing the trust path of the maintainer of your software would be useful, even when they're not a DD. Whatever the name. I was just reminded that a NM keyring would be usefull for tracking the NMs packages and similar jobs. The AM checks the signatures and ID. If there is NM keyring the AM adds the key to you would have some security and someone directly responsible for adding the key for each NM without being overworked. 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. I'm not likely to get an S/390 anytime soon (although donations are, of course, more than welcome). g But I'm happy to put multiarch building into the system if you'd be willing to run a buildd for it (I'm depressingly single-arch these days). I was more thinking along the line of having at least i386, ppc and alpha or amd64. i386 (or ppc) should usually cover having the same system the uploader had. ppc has different chars (and endianness i think) and alpha/amd64 for a 64 bit arch. Shouldn't be hard to get those. 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. Hmm, yes. What I've got at the moment is tarballs built from the autobuilder output, with the .dsc, everything mentioned in there, and the build log. My thought was that sponsors, when they wanted to get something to sponsor, would download that tarball (everything you need in one easy package). If you think it would be more helpful, I've already got a package pool set up internally that I can easily convert for the purpose if needed. For signing the build log (sbuild includes the changes file) or the changes file is needed. For testing or fetching source a repository is easiest to install, at least thats what I came to for my own packages. * 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 I'm wondering if that might be sailing a little close to the
Re: Multi-person sponsorship
On Tue, Feb 17, 2004 at 11:57:55PM +1100, Matthew Palmer 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. 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. 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. 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. -- Jamin W. Collins To be nobody but yourself when the whole world is trying it's best night and day to make you everybody else is to fight the hardest battle any human being will fight. -- E.E. Cummings
Re: Multi-person sponsorship
Matthew Palmer [EMAIL PROTECTED] 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.
Re: Multi-person sponsorship
Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? This could be done completely automatically. Cheers T. -- Thomas Viehmann, http://beamnet.de/tv/ pgpLvo74gKGua.pgp Description: PGP signature
Re: Multi-person sponsorship
Thomas Viehmann [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? This could be done completely automatically. Cheers T. Because then you would need a DD sponsoring your uploading sources to the sponsoring pool be sponsored by a DD after build. The check is ment for the source so as not to build just anything. MfG Goswin
Re: Multi-person sponsorship
Goswin von Brederlow wrote: Thomas Viehmann [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? ^^^ the key, not the package This could be done completely automatically. Because then you would need a DD sponsoring your uploading sources to the sponsoring pool be sponsored by a DD after build. The check is ment for the source so as not to build just anything. I'd think you misunderstood me, but it might be vice versa... Cheers T. -- Thomas Viehmann, http://beamnet.de/tv/ pgp9Si3Ag3kIn.pgp Description: PGP signature
Re: Multi-person sponsorship
On Tue, Feb 17, 2004 at 07:11:08PM +0100, Goswin von Brederlow wrote: 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? If the .changes isn't signed by a key in the uploaders keyring, it gets rejected. The exact criteria for who gets their key in hasn't been thought about yet - so far, it's been people I intend to sponsor. I presume it'll be something like that in the future, too. I hope you destroy the chroot after each build and unpack it anew. Sing it loud, and sing it clear - We love pbuilder! We love pbuilder! 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. I hadn't thought about an NM keyring, but that has a certain amount of sense to it. I'd like to not limit the sponsorship service to just people who are in the NM queue, but even a sponsee keyring - perhaps separated by NM/non-NM - would be of definite benefit. Knowing the trust path of the maintainer of your software would be useful, even when they're not a DD. 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. I'm not likely to get an S/390 anytime soon (although donations are, of course, more than welcome). g But I'm happy to put multiarch building into the system if you'd be willing to run a buildd for it (I'm depressingly single-arch these days). 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. Hmm, yes. What I've got at the moment is tarballs built from the autobuilder output, with the .dsc, everything mentioned in there, and the build log. My thought was that sponsors, when they wanted to get something to sponsor, would download that tarball (everything you need in one easy package). If you think it would be more helpful, I've already got a package pool set up internally that I can easily convert for the purpose if needed. * 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 I'm wondering if that might be sailing a little close to the wind, though. I'd prefer not to fiddle with the way things are done too much this early, and automating uploads feels a little too much like it's ripe for abuse. At least this way, since it's going to take the sponsor some time just to build the package ready for sign+upload, hopefully they'll spend the extra time looking for problems and maybe trying the package. 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. This isn't a bad idea. I might have to get a little funky with my mod_rewrite skills (pitiful as they are) and get something going so I can do some reference-counting (and general funky stuff). * 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. So I still have to write my MIME-aware mail checker? Bummer. grin * Once selected by a sponsor, a package for sponsorship is
Re: Multi-person sponsorship
Thomas Viehmann [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Thomas Viehmann [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: 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. Why not just check if the key is signed by a key in the debian keyring? ^^^ the key, not the package This could be done completely automatically. Because then you would need a DD sponsoring your uploading sources to the sponsoring pool be sponsored by a DD after build. The check is ment for the source so as not to build just anything. I'd think you misunderstood me, but it might be vice versa... Yes, I did. MfG Goswin
Re: Multi-person sponsorship
Matthew Palmer [EMAIL PROTECTED] writes: On Tue, Feb 17, 2004 at 07:11:08PM +0100, Goswin von Brederlow wrote: 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? If the .changes isn't signed by a key in the uploaders keyring, it gets rejected. The exact criteria for who gets their key in hasn't been thought about yet - so far, it's been people I intend to sponsor. I presume it'll be something like that in the future, too. That was what I had in mind, just everyone in the sponsoring group, or any DD, should be able to add or remove keys. Or accept any key signed by a DD or something that won#t be as hard as becoming a DD itself. I hope you destroy the chroot after each build and unpack it anew. Sing it loud, and sing it clear - We love pbuilder! We love pbuilder! 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. I hadn't thought about an NM keyring, but that has a certain amount of sense to it. I'd like to not limit the sponsorship service to just people who are in the NM queue, but even a sponsee keyring - perhaps separated by NM/non-NM - would be of definite benefit. Knowing the trust path of the maintainer of your software would be useful, even when they're not a DD. Whatever the name. I was just reminded that a NM keyring would be usefull for tracking the NMs packages and similar jobs. The AM checks the signatures and ID. If there is NM keyring the AM adds the key to you would have some security and someone directly responsible for adding the key for each NM without being overworked. 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. I'm not likely to get an S/390 anytime soon (although donations are, of course, more than welcome). g But I'm happy to put multiarch building into the system if you'd be willing to run a buildd for it (I'm depressingly single-arch these days). I was more thinking along the line of having at least i386, ppc and alpha or amd64. i386 (or ppc) should usually cover having the same system the uploader had. ppc has different chars (and endianness i think) and alpha/amd64 for a 64 bit arch. Shouldn't be hard to get those. 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. Hmm, yes. What I've got at the moment is tarballs built from the autobuilder output, with the .dsc, everything mentioned in there, and the build log. My thought was that sponsors, when they wanted to get something to sponsor, would download that tarball (everything you need in one easy package). If you think it would be more helpful, I've already got a package pool set up internally that I can easily convert for the purpose if needed. For signing the build log (sbuild includes the changes file) or the changes file is needed. For testing or fetching source a repository is easiest to install, at least thats what I came to for my own packages. * 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 I'm wondering if that might be sailing a little
