Alle 04:08, martedì 11 gennaio 2005, hai scritto: > 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.
unfortunately, you're right. > 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. yes, since the wget website is just a couple of pages of text, according to the FSF policy i moved the official wget page from wget.sunsite.dk to gnu.org. unfortunately, i got access to the wget.sunsite.dk site only yesterday (and i haven't checked if it works yet), so i will start making changes on that server soon. > The mailing list archives are on three unrelated domains. yes. actually, i don't even know who is in charge of managing those archives. shame on me :-( > The new bug tracker is at <http://wget-bugs.ferrara.linux.it/> but I only > found that using Google. yes, i haven't published that address on the website yet. read below. > The older, unofficial bug tracker at <http://bugs.debian.org/wget> might > still turn up for some people searching at Google, too. i think you're wrong this time. IIRC, that one is the bug tracker for the debian package of wget. > That's a lot of domains. unfortunately, you're right. but i don't think having a lot of domains would be really a problem if the information on the main page would be more readable. > > 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/>. well, i am sorry for that, but this was stated in the official wget website, on the development page: http://www.gnu.org/software/wget/wgetdev.html#development this time it is your fault ;-) > 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. oh, i don't think you're stupid at all! instead i really appreciate your interest, your information usability analysis and the suggestions you are submitting. > Compare the wget website to some other open source projects like GCC > (<http://gcc.gnu.org/>) and Subversion > (<http://subversion.tigris.org/>). well, i understand your point and i agree with you on this, but i can think of almost 1000 different open source related websites (e.g. the libtool, gaim and python) that are much better than the gcc and subversion websites, as i don't really like those two sites. > 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. that's a very good idea! > 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?). yes, i've had only a very limited time to work on the website and i didn't want to make big changes, but just to update the information. for what regards the bug tracker, what you say is right. the only reason for which i didn't give the announcement on the website is that i am not very familiar with bug trackers and i thought that at first i could just fill in the tracker database myself copying user reports from the mailing list, in order not to pollute the database with user reports and requests. now that i have been using roundup for some time and i have been impressed by how easy to use it is, i think we should really change policy and start asking users to submit features whislists and bug reports via the bug tracker. > 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. oh, not at all! believe me or not, i really appreciate your email. > I would like to see all of this disparate stuff cleaned up and put on a > single, easy to navigate server. now, this would be really a great idea! would you be interested in taking care of the new website design/development? > 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 don't think we need a new server to setup such a website, as we could as well use wget.sunsite.dk or cadalboia.ferrara.linux.it (the server that hosts our bug tracker). > > 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 yes, we have to come up with a bugfix and/or a different name for strings.h. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi University of Ferrara - Dept. of Eng. http://www.ing.unife.it Institute of Human & Machine Cognition http://www.ihmc.us Deep Space 6 - IPv6 for Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
