Re: [Cvs-dev] Help CVS Project Solicitation

[Bob Proulx]

Thorsten Glaser wrote:
> I guess the source code could stick there, under certain circumstances,
> however it's still overhead (more than one mailing list, which could be
> shrunk down of course though, and web-based forum/tracker/etc. stuff,
> which is just... annoying to Lynx users).

This immediately puts me in the position of being the defensive
responder.  I guess I did already say that I would be sad to see cvs
go elsewhere.  However CVS is not a GNU Project project.  If the heir
apparent for CVS is hosted elsewhere I would be okay with it.  I would
support it.  I would help.  Many projects are hosted many different
places.  Even many official GNU Project projects such as GCC are
hosted elsewhere.

But let me answer your questions.  Even if you don't like Savannah.

You can change the mailing lists to be anything you want them to be.
The CVS project maintainer created the current mailing lists.  That is
why they are there and named what they are named.  Personally I always
thought that info-cvs was an unusual name for generic discussion.
Worse is that I think it is confusing because most info lists are
announcement only lists without discussion.  Except for AFAIK info-cvs
which uniquely is a discussion list.  Personally I prefer a help-cvs
generic discussion list and a bug-cvs bug reporting address list.  But
note when I say "prefer" it is simply that, a preference, and there
are many different ways to do things.

Note that mailing lists are handled over at lists.gnu.org and aren't
part of Savannah.  (I also happen to be one of the mailing list
volunteers too.  But Savannah and the mailing lists are almost
completely separate entities.)  Note also that there is much
documentation all over the internet that references the current
info-cvs mailing list.  People will continue to mail there for years
and years even after it is gone.  The fileutils, shellutils, and
textutils mailing lists were converted to the coreutils in 2003 and we
are *still* getting email sent to the old mailing lists.  There is
something to be said for stability.

Personally I really don't like the Savannah web based bug tracking
system that is currently in place.  I find many of the newer web based
trackers such as Redmine to be much better.  Remember that Savannah
was originally a fork of the last free SourceForge and many things
were inherited from there.

But there is no requirement to use the Savannah web tracker.  Among
the projects I am more closely associated with they are all using the
Debian BTS system.  Glenn Morris maintains an instance of it at
https://debbugs.gnu.org/ and I suggest using it instead of the
Savannah web based tracker.  However it isn't required that
debbugs.gnu.org be used either.  GNU Bash for example doesn't use any
tracker beyond the bug-bash mailing list.  What is used is up to the
project to decide.

I am not often using lynx but I do often use emacs-w3m and emacs-eww
and will assume the experience is similar.  Which is to say not very
nice.  But in defense there I will say that using Chromium or Firefox
on the web site is also not great either.  I recommend setting the
"Stone Age menu" option.  One thing that has been in need for a long
time is some love and attention applied to the Savannah web interface.
It still looks like the old SourceForge fork.  Fortunately the web
interface isn't in the work flow path of anyone using the version
control repositories.  Users using cvs, git, svn, hg, bzr, and so
forth all use the native vcs commands to interact with the source
files.

Having said all of that if there are any particular problems with
using Savannah's web interface with lynx or any other browser that
breaks being able to use it then please let us know about it.  It
should be fixed.  Better still would be someone to help improve the
web interface.

Really only need for the web interface is to enable and disable
features (cvs, svn, git, bzr, hg, or triggering the creation of
mailing lists) and to add or remove people from having commit access
to the repository.  Those aren't daily actions.  Just things that need
to be done once in a while when the need arises.  Which is good
because the web interface to the controls is not nice.

Most of my personal user interaction with Savannah is through the
revision control tools interacting with cvs, git, and svn files.  I
check out source files, make modifications, commit them back using the
native command line interfaces of those tools.  I look at logs.  I
make branches.  All of those use Savannah but none of them use the web
interface.

I know a lot of people today feel the need for a github style web
interface with the ability to edit files directly on the web and to
submit github pull requests.  There has been continuing ongoing
discussion about whether Savannah needs to implement a github style
web frontend or not.  And of course there are various projects right
now such as GitLab and others.  But if anything Savannah's long life
and SourceForge inheritance should show people that deciding to use
something like GitLab or others is a long term marriage.  Will that
interface continue to be supported for the next decade and beyond?
Will the user interface be appropriate a decade and beyond?  Marriages
are not something to be entered into lightly.

> http://savannah.nongnu.org/cvs/?group=cvs says "Getting a Copy of the
> CVS Repository" but only contains instructions on how to get a checkout
> (working copy), not an actual copy of the repository.

We would love people to help improving the web interface.  :-)

> Can I use rsync over ssh, after recovering my account, to get the
> actual repository, over authenticated and secure transport?

Of course you can rsync any of the repositories.  Try this:

  rsync cvs.savannah.nongnu.org::
  rsync cvs.savannah.nongnu.org::sources/

I know you said secure transport.  For members of any project you can
use ssh access.  Presently one must be a member of any project, more
than just registering an account but also a member of any project, in
order to have ssh access.  Commands are restricted.  General shell
access is not allowed.

Try this for ssh access.  Where $USER must match your Savannah member
account name.

  rsync address@hidden:/sources/cvs/

And of course that applies to all of the other version control systems
too.  Modify the paths as appropriate to get to the other files.

> If so, how, and why is that not documented?

As to where this is documented the documentation was, past tense, in
the form of a wiki.  Wikis are great when there are many eyes to look
at things and prevent spam.  But not so good when there are not.
Wikis become link spam farms unless watched over.  At the present time
the documentation is read-only unless a member of the project due to
past history of spam.  I say it was a wiki because that also describes
the documentation.  You know how wikis can be, somewhat eclectic.

It would be wonderful if someone were to volunteer time and effort to
organize and improve the documentation.  Instead we spend our time
working on other things.  There are no paid staff positions here.  We
are all volunteers.

  https://savannah.gnu.org/maintenance/AccessToCVSROOT/

And rsync access is also mentioned here too:

  https://savannah.gnu.org/maintenance/CvSToSvN/
  https://savannah.gnu.org/maintenance/CvsRsyncWriteAccess/

> If not, Savannah fails at code hosting.

I know you don't like Savannah.  You started out with an opposition
stance from the beginning.  You don't ask, how is something done,
assuming that it is possible.  Instead a challenge is thrown with the
conclusion already presented that it is a failure.  That is not
working in good faith.

I am not here to try to change your mind about Savannah.  I am not
going to hide problems that exist with Savannah.  If you really hate
having the source code hosted on Savannah then by all means move it
elsewhere.  Libre software is all a labor of love.  And if you don't
love it then there is no motivation for the labor.  I will still be
sad to see it go.  Because again the community is larger than any one
individual.

Bob