From: Matthias A. <mat...@gm...> - 2007-03-18 23:44:52
|
Jochen Hayek schrieb: >>>>>> "MA" == Matthias Andree writes: > >> Jochen Hayek writes: > > MA> But why would fetchmail then need its own command line switch at all? > > Because that feature needs to get locked out, until it gets explicitly invited. > > And the fact that ready-made fetchmails in distros come with not so obvious linked-in socks support > is not really a contradiction, > to the fact, that people don't want that feature until they say "I want it". Well, this feature has been automatically enabled in fetchmail since at least 6.2.5, and I think we should keep breaking compatibility in this respect until the next minor or major release -- I'll certainly consider changing the default for fetchmail 6.4 or 7.0 or whatever version, and I'm very much inclined to choose defaults that do not surprise the user. I wonder if there is really a common expectation. Other users might expect that *if* they have a socks.conf, *then* socks-enabled applications should use it. This isn't clear to me, and it's a bet the maintainer will always lose - one group will be happy and quiet, and the other group will shout. :-) > Because a fetchmail switch "--use-socks" defaulting to false > would have helped not costing me and others quite a couple of hours. Sorry for that - it's documented now <http://www.fetchmail.info/fetchmail-FAQ.html#K1> and will also be documented in the manpage of fetchmail 6.3.8. Feel free to suggest further changes, the FAQ is surely not cast in concrete. > A good example for the downsides of the bazaar approach ... > (Sorry for this, but I couldn't resist.) Not my essay, and I'm not enthusiastic about several of the assumptions fetchmail makes, and I'm still pondering whether a complete redesign is more of an effort than rewriting existing code... I sympathize with you on the bazaar "appreciation", too. The "many eyeballs" argument that is invoked so often doesn't hold water IMO - those eyeballs are only looking after someone has encountered a *local* problem (or in the rare case some distributor pays for the audit or some company tries their automated code validator and shares the results). The accumulation of dozens of patches, with uncorrected programming styles, which are really just patches that have often not properly been integrated - this is a constant headache, and the security fixes that went into 6.3.6 had to be large as a result of these inconsistencies and ad-hoc hacking -- and the fallout caused regression fixes in 6.3.7 and 6.3.8. This is the thing I feared most, I did several 6.3.6 release candidates, but still only field deployment revealed these issues. :-( Getting distracted a bit, I'd also say beta and rc versions don't work without contracted beta testers, since users will just wait for the final release out of convenience - and that's understandable, consumers don't want unripe garbage... > A couple of words in the man page and in the FAQ, > that will get found by search machines, > so that googling for "fetchmail socks" > will immediately reveal the problem. Search engines aren't under my control -- let me know if you want anything else or suggest changes to the FAQ URL I've given above. > But still: > when *I* couldn't connect to my ISP's IMAP server any longer > I was ***far*** away from googling for "fetchmail socks", > and it took me pretty long to find out, > that I had gone through my socks server for quite a while > (without being aware of it, as I never told fetchmail to do so) > and that I could not connect to the IMAP server, only because my socks server was down. If fetchmail were actively enabling socks, then we might just log additional information to the connecting... ("via socks server XYZ port N") but this isn't the case. I haven't looked too deep into SOCKS yet and I'm short on time. I plan to do 6.3.8-rc2 this week and 6.3.8 this month, so that I can move on to actually opening the 6.4 branch. -- Matthias Andree |