El 10/01/2005, a las 20:43, Mauro Tortonesi escribió:
(Yes, there are no doubt some web-based archives of the mailing list, such
as <http://www.mail-archive.com/wget%40sunsite.dk/>, but there's no single
official archive linked to from the official wget page or in the wget
documentation.)
well, the official wget page:
http://www.gnu.org/software/wget
reports the following URLs:
http://fly.cc.fer.hr/archive/wget http://www.mail-archive.com/wget%40sunsite.dk/ http://www.geocrawler.com/archives/3/409/
as mailing list archives. perhaps you're suggesting we should choose one of
them as the "official" one?
I guess the problem is that none of them are official are they?, and there's no guarantee that they'll continue to be provided. The information is out there, but it can be hard to find. In fact, I think information about wget is generally hard to find. Consider that there's the official wget web page, then the page at <http://wget.sunsite.dk/> which could easily be mistaken for the official page too. The mailing list archives are on three unrelated domains. The new bug tracker is at <http://wget-bugs.ferrara.linux.it/> but I only found that using Google. The older, unofficial bug tracker at <http://bugs.debian.org/wget> might still turn up for some people searching at Google, too. That's a lot of domains.
this is my fault. i tested the code under linux and it worked well. i didn't
have any other platform to test it so i did what developers are supposed to
do in this case: just commit the code and wait for someone like you to send a
bug report ;-)
Fair enough. Unfortunately I didn't know enough about using CVS from the command line to find out exactly what had changed. I would have liked to look at the repository using cvsweb, but I only discovered <http://cvs.sunsite.dk/viewcvs.cgi/wget/> (found via Google) while doing the research for this email I'm writing now. I then went back to the wget website and found <http://sunsite.dk/cvsweb/wget/>.
Now, it's not that I am a stupid person, or that I refuse to read. On the contrary, I have tried to read the wget website, but it just doesn't lend itself to being read. It's easy to overlook things. Usability studies show that humans scan and read websites in a different way than they read books.
Compare the wget website to some other open source projects like GCC (<http://gcc.gnu.org/>) and Subversion (<http://subversion.tigris.org/>). These sites have a navigation bar on the side, and that's what the wget site should have too, I would argue. The closest thing the wget website has is its table of contents:
* Introduction to GNU wget * News * Downloading GNU wget * The GNU wget FAQ * Documentation * Mailing lists * Request an Enhancement * Report a Bug * Add-ons * Development of GNU wget * Maintainer
I would argue that instead of the table of contents there should be a navigation sidebar with a structure something like the following:
* About GNU wget * News * Download --> Mirrors --> Binaries --> CVS * Support --> FAQ --> Documentation --> Mailing lists * Contributing --> Request an enhancement --> Report a bug --> Developer's guide --> CVS access * External links --> Add-ons
That's just a rough idea, but it would bring it in line with what people expect based on the vast majority of websites out there.
As it is, things are very confusing. The wget project is spread out over half a dozen unrelated domains and even more subdomains. There's a "discussion" list and a patches list. Users wishing to report a bug are told to post it to [EMAIL PROTECTED], but that just forwards to the "discussion" list (why aren't users told to use bug tracker?). Users wishing to request an enhancement are told to post it to the discussion list (strictly speaking, enhancement request belong in the bug tracker too, don't they?).
I know that your principal concern right now Mauro is working on the code, so please don't take all these comments about the wget website as demands that you do something about it. I merely wanted to put these thoughts on the record and hear what other people think about them. I would like to see all of this disparate stuff cleaned up and put on a single, easy to navigate server. It would be useful to know some kind of usage statistics (traffic, number of users) so as to know what kind of sponsorship would be needed to set that kind of thing up.
i'll fix this problem ASAP. anyway, i suddenly realize string.h is probably a
very poor choice for a filename to be included in wget.
For the record, strings.h would probably be a bad choice also. That is also the name of a system header file on Mac OS X.
-r--r--r-- 1 root wheel 4886 14 Sep 2003 /usr/include/string.h -r--r--r-- 1 root wheel 2874 14 Sep 2003 /usr/include/strings.h
On FreeBSD (4.x, at least) those files are at:
-rw-r--r-- 1 root wheel 4208 Dec 25 2001 /usr/src/include/string.h -rw-r--r-- 1 root wheel 1895 May 24 1994 /usr/src/include/strings.h
Cheers, Greg
