[Savannah-hackers] Re: bug in Anon CVS how to

[Robert J. Chassell]

   ... this file is created automatically by the cvs software.

That makes sense.

   You are the first one too report such a problem. Which CVS version do
   you use?

Both of the machines i tested this on are running:

     $ cvs --version

    Concurrent Versions System (CVS) 1.11.2 (client/server)


   ... If it's abnormal that this file .cvspass is created
   automatically, ...

I do not know whether it is installed abnormally or not; but both
machines are running Debian testing, which is a major GNU
distribution.

It is certainly easy to miss this problem, either because the CVS in
your distribution creates a ~/.cvspass file automatically if none
exists, or, as in my case, if someone has had a ~/.cvspass file for
years and never thinks of it.

   ... People that use misconfigured tools ....

In this case, it might be a Debian bug, but the tools were not
misconfigured by the installer, I can assure you of that.  The install
was for Debian.

   We musnt provide informations about all potentially issues on
   Savannah. On Savannah, we need to provide the normal way to do things
   and a way to solve common troubles.

The point is to find out the potential issues and to fix those.  You
can presume that the people who become Project Administrators on
Savannah are trying as hard as they can.  It is better to provide more
info rather than less.  You hurt people when you hold back on
information that you know that would help someone if you told them.


   People expect this. They surely do not want to read 1500 lines of
   documentation with 1459 lines related to bugs that only one person
   had in two years.

Right -- that is why you write and arrange the documentation so it
helps the reader, rather than arrange it so that the person must read
it all.  That is why, for example, it did not occur to me to read
through the FAQ.  My assumption was that only the questions that
appeared relevant to me would contain information that is relevant to
me.  As you pointed out, I was wrong.  But your point is right:  a FAQ
or other help document should be designed so that you do not have to
read 1459 lines just to find the one line that is relevant.  ,

   For those so rare issues, we will answer case per case at
   savannah-hackers. 


   > But someone should also mention that sometimes subversions.gnu.org
   > is down or otherwise undetectable by a normal account at a normal
   > site ...

   This problem can have lot of cause. It can depends on the AOL network,
   and anything else. Normally, it does not depends on the Savannah
   installation but on the DNS. 

I know all that.  The point is, Savannah comes across to me as a
somewhat flakey site.  I am not sure whether it really is; but that is
how it appears to me. (I usually contact it once a day for a CVS
update on another project.)  

The site administration situation is similar to the one involving
mailing list creation.  Savannah tells me that the automatic tools for
a mailing list require several hours.  So long as I know that, all is
well.  I wait until what I presume is a cron job gets done.  But if
Savannah were not to tell me to wait several hours, I would check as
soon as I received an `Update Successful' message.  And if things
failed then, I would presume that the `Update Successful' message was
wrong and that Savannah is broken.   


   Why limiting this documentation to savannah ? Why writing something
   specific while we can write something general, that will work for any
   CVS installation ?

Yes, you are right.  It is better to write generally, so long as you
do not detract from the Savannah documentation.  The Texinfo that I
wrote about how to use anonymous CVS is aimed to Savannah, but should
work for any CVS installation.

   If I type C-h i, I see a CVS section. If this documentation is too bad
   to understand how to use savannah, why not rewriting it?

Understanding that document requires that that a reader be more
interested in CVS than many have time for.  I have looked at it; that
was among the first things I did when I first began using CVS
regularly.  It did not help me then so I stopped using it except for
the occasional look up.  

Yes, it should be pointed to by a cross reference.  No, you should
not expect a Project Administrator to have the time or interest to
read it.  

   Anyway, note that savannah isnt really a website but a
   software. 

I know that:  but the savannah.gnu.org Web site is the instance of
the software with which I am dealing.  What I want to do is use the Site.


   Content is generated dynamically. So it's not texinfo
   files. 

The source for all the documentation should be in Texinfo format.  It
is a bug if it is not.  With Texinfo format, not only is it easy for
site administrators (or their tools) to create HTML, but it is easy
for them to print out the info so they can review it in a different
format than usual (which enables them to see problems that they might
otherwise miss).  Moreover, Texinfo enables busy Project
Administrators and others to print out docs to read off line.  Texinfo
enables efficient people to read the docs in Info, which is much
better than HTML for navigation, and be disconnected from the Net.

-- 
    Robert J. Chassell            address@hidden  address@hidden
    Rattlesnake Enterprises       http://www.rattlesnake.com
    Free Software Foundation      http://www.gnu.org   GnuPG Key ID: 004B4AC8