This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Zapping the old FAQ


Gerald Pfeifer wrote:
> 
> I spent some time thinking about the F-O-M, and here are some issues I
> noticed:
> 
>  o You once expressed the wish to also have the FAQ in texinfo format and
>    then convert it to HTML for the web, info for the distribution, etc.
>    How can we do that with the F-O-M?

Not well. Making unugly texinfo from HTML isn't easy. For this
degenerate case, it could probably be done. Determining if it's
worthwhile is an exercise for the reader.

>  o We currently ship (and probably want to continue to do so) our FAQ with
>    releases. This will become harder with the F-O-M.

It can be automated; perhaps even via the snapshot process.

While I don't have reasonable web access from where I am, there are
several options in the FOM that can be set; I think they default to
pushbuttons at the bottom of the page. Buttons include "use simple HTML"
and "display everything from here down". Click one or both of those and
note the options appended to the URL. Now use 'lynx -dump' (or another
HTML->ascii converter of your choosing) to dump the resulting URL to a
file.

When I maintained the comp.unix.sco.programmer FAQ, I used to use this
for periodic inclusion on CD's for periodic newgroup posting, and so on.
This could be done in the snapshot if so wanted. I used to do it from a
cron job.

>  o For our web pages we have a kind of peer review system, which often
>    leads to suggestions and enhancements (often by means of private mail
>    to me, for example).
> 
>    We can easily discuss changes to the FAQ on the mailing list and see
>    notifications via gcc-cvs-wwwdocs and have everything archived in list
>    archives. Is there some way we can keep that?

You could crack open the RCS files to generate "patches" that resulted
from the user edits.

>  o F-O-M cannot be mirrored easily by other sites, most notable
>    www.gnu.org.

The FOM data files are kept in a well-defined directory structure.
Mirror the files like any other.   


> Sorry, if this sounds negative, it just wanted us to have a look at some
> disadvantages we might have in addition to the clear advantages we'll
> gain.
> 
> (As you all probably know, I am really not territorial when it comes to
> the web pages, so this is *not* the reason I am raising these issues!)


The issues you raise are all real. There are tradeoffs to make.   The
"solutions" I suggest above may or may not be worthwhile to you.

In general, the FOM is better at _giving up_ control than at delegating
it.

RJL

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]