Hi Daniel - sorry, but someone else from Savannah will need to work with
you to move this forward. I just can't undertake the project.
Project maintainers on savannah cannot create their own git repos. They
have send email/submit a support request. (This is a constant thorn in
everyone's side.)
I guess your proposal is intended to avoid any work being necessary on
the Savannah side. I can understand that goal.
All that said, let me just say that the interface that seems cleanest to
me would be to change new.py to take an additional option to specify the
web repository VC type, say "-R cvs" or "-R git".
Then, on the savannah side, git would have to be supported as a backend
for web repos as well as cvs (database work, UI work). On the fsf side,
it would be a matter of running git commands instead of cvs commands,
but following exactly the same pattern.
But, as I say, I'm not going to be the one to move this forward, so I'm
not going to complain about whatever happens.
Also, I saw that there is a script to generate documentation for
each project. I think it runs on the Savannah side of things but
want to confirm.
"Generate documentation"? Sorry, I don't know what you're referring to.
If you mean the output for Texinfo manuals in different formats, like
the links on https://www.gnu.org/software/emacs/manual/, they are
(usually) generated by the gendocs.sh script, which is maintained in the
gnulib project. Project maintainers run it themselves; Savannah per se
is not involved.
Or, maybe you noticed that Savannah inherited a concept of "User Docs"
("Cookbook" and "In Depth Guide") from its parent software, but
essentially no projects use them, as far as I know. They are always just
boilerplate. (I wish it were possible to turn off the links in the menu.)
All the best,
Karl
