--- "Dimitrie O. Paun" dpaun@rogers.com wrote:
On Fri, Mar 18, 2005 at 02:04:08PM +0100, Francois Gouget wrote:
But I don't see any reason not to put it in
wine-doc-html.tar.gz or
wine-doc-txt.tar.gz. The idea of these tar files
is so that one can get
all the Wine documentation with just one download
and the FAQ is part of
the documentation.
Yes, but I can not possibly see why would anyone want to download and read the FAQ like this. A FAQ is essentially a Web type of document, best view and browsed on the Web. By including it in those packages, we just make them bigger for 99.99% of the users that don't care about the FAQ, and those users are probably the ones that have most bandwidth restrictions anyway.
But I'm not totally against it being there, if people feel strongly that we must, I'll go with the flow.
As a web developer (and Wine user), I feel inclined to believe that all major documentation should be removed from the source. A README file pointing the user to the web site for the latest documentation would be most efficient and beneficial.
Basically, by doing this, users will begin realizing that if they want documentation, WineHQ is the place to go. In a sense, it is streamlining information. Not only does this reduce user confusion, but it also minimizes the propagation of old documentation which no one will have the power to update. By not consolidating the documentation resource, there will eventually be a certain percentage of the Wine userbase trying to follow outdated Wine documents.
Hiji
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
On Fri, 18 Mar 2005, Hiji wrote: [...]
As a web developer (and Wine user), I feel inclined to believe that all major documentation should be removed from the source. A README file pointing the user to the web site for the latest documentation would be most efficient and beneficial.
I always find it annoying when I cannot go to /usr/share/doc/<package> name to find documentation for some piece of software. Granted that's for Debian packages but the principle is the same if you download the wine binaries and the corresponding wine documentation tarball.
Also, once compressed the Wine FAQ is less than 23KB which is not much even for a modem (less than 10 seconds). And modem users are also those who are the most likely to pay their Internet access by the minute.
Basically, by doing this, users will begin realizing that if they want documentation, WineHQ is the place to go.
Again this will greatly penalise modem users with per-minute Internet access fees (i.e. phone bills).
In a sense, it is streamlining information. Not only does this reduce user confusion, but it also minimizes the propagation of old documentation which no one will have the power to update.
[...]
IMHO removing the documentation from the main Wine sources means it is much less likely to get updated because developers will have to get out of their way to even get its sources.
Also you may limit the spread of old documentation but you will instead end up in the situation where only documentation available will be the one for the latest Wine and users who have a slightly older Wine will have no documentation at all.
Sure right now you'd better use a pretty recent Wine anyway but this will have to change one day (e.g. when we reach 1.0).
Le ven 18/03/2005 à 13:14, Hiji a écrit : [snip]
but it also minimizes the propagation of old documentation which no one will have the power to update. By not consolidating the documentation resource, there will eventually be a certain percentage of the Wine userbase trying to follow outdated Wine documents.
As long as they follow the docs on the same Wine snapshot from which their documentation came, it's good by me. Mixing new docs with old Wine will do no good ("I have symlinks in my ~/.wine/dosdevices, but Wine is expecting drive definitions in config"), as well as mixing old docs with new Wine ("I don't have a config...").
I think most binary packages already provide the docs in a compiled form. If they do not, they should do so, at least in a wine-doc(s) package (if that's the distribution way of doing it), or in the main wine package.
Vincent