Geert Stappers <stapp...@debian.org> writes: >> >> Of course, incomprehensible questions will also drive users elsewhere, >> so we need to make sure that people understand that they almost >> certainly don't care, unless they already know that they do care. > > This e-mail is about "worry about a proxy > when there is need to worry about a proxy" > >> I could imagine using auto-detection to populate default values for a >> site's proxy, assuming that the software to achieve that has a decent >> chance of success, and isn't too big. >> >> Alternatively, one could make sure that the subsequent package download >> progress page made it clear that it would be safe to cancel that, and >> that doing so would let one back up and specify a proxy to go via and >> then retry the install -- that would let the person looking at a >> download that's going depressingly slowly plenty of time to remember >> that they have a faster alternative, and the reassurance that they can >> switch to it without having to start the install from scratch (assuming >> we can get the code to work that way). > > Currently we have these steps > > * hardware detect > * network configuration with DHCP and manual config upon fail > * allways ask for proxy > * do the download > > What I would like to see, are these steps > > * hardware detect > * network configuration with DHCP and manual configuration upon failure > * inform user there is test download going on, allow "quick fail" (don't wait > for time out) > ** upon fail: ask for a proxy configuration > ** upon succes: fine, just continue > * do the download
Which in the case I described, would result in a probe that would succeed followed by a download that was going to take several days. I'm not trying to claim that it's a common case, but I've also certainly done many slow installs by over-enthusiastically hitting return and then remembering that there is a caching server locally that I should have specified. Actually, I was assuming that the scenario you describe would provoke the same behaviour as the user interrupting the slow download, so I agree that a failed download should also allow one to specify a proxy. I am sceptical that a reliable test can be constructed that isn't going to be just doing the download, so if we're going to change things it should be to deal with all errors that might point at the need for a proxy, including being aborted by a user during the download. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
signature.asc
Description: PGP signature
