john s jacobs anderson <jacobs(a)azstarnet.com> writes:
 I do think a Minister of Information-Dissemination type position is
a
 good idea. That is, a person _ultimately_ (but not necessarily
 _personally_) responsible for the FAQ, coordinating the documentation
 versions and formats, announcing releases to Freshmeat and the
 newsgroups, evangelism and proselytizing, etc., etc. 
I agree. It used to be that the "XEmacs maintainer" (currently Steve)
was responsible for that (as well as deciding which apaches to apply).
We shifted the patches burden, it seems like a good idea to this with
the PR too.
 Of course, if you've got access, feel free to do it yourself,
also. Send 
 me a note and let me know, or at least modify the comments in the page 
 header. (Add another <META type="author"> tag.) 
This is basically what CVS is all about.
 We've already got the submission/confirmation part (mail
 webmaster(a)xemacs.org stuff, I (or somebody else) posts it, we tell you
 it's posted). The only advantage to CVS would be (1) maintaining a
 local 'source' tree for the web site and (2) making sure two people
 weren't editing the file at the same time. 
No (by default CVS doesn't even do (2), although it can). The main
advantage is keeping track of changes. This already a huge advantage
when working alone and it is a must-have when working with others.
 
 Is that worth the effort, or is there something I'm missing?
Setting up and using CVS is fairly simple. There is just two points to 
keep in mind
1. Due to a design error in CVS moving/renaming files is harder than
   it should (not impossible just less convenient then it should be).
2. The perfect solution would a web-server (a mod_cvs for apache) than 
   can serve directly out of CVS. However this currently impossible.
   Thus you need to CVS checkout the file on the web server. Either
   you do this manually and then it isn't much different from using
   ftp to update the site or you have the webserver do this
   periodically. The last solution is harder, but has the advantage
   that not everybody needs access to the Web server.
The manual solution would look something like (after initial setup)
# Send your changes to the repository 
cvs commit
# (optional)
# Tell the CVS server that the state as now is ready for release 
cvs tag public
# Tell the webserver to get the changes from CVS
ssh 
www.xemacs.org cvs update
In "automatic mode" the last line would be done by a cron script on
www.xemacs.org. 
 
 >     Jan> [2] Note: That is maintenance, _not_ design. I think we are
 >     Jan> disciplined enough to keep a make minor (but possibly crucial
 >     Jan> information wise) changes in accordance with your style
 >     Jan> guides if you are on that round the world trip.
 
 I don't know if I'm on 'that round the world trip', 
What was trying to say (in a humorous way,  but it failed) that we
should plan for the contingency of you (or anyone else) being
unavailable (such as after you won the lottery and when on a  round
the world trip). Thats why I brought up CVS because it means that
others have access to the master copy of the website and in case of
"automatic" updates that access to CVS is sufficient to update the
website. It also means that people should have the discipline to not
do this until absolutely necessary.
 CVS-guru's: Can the CVS system check to make sure a particular
feature 
 exists in a file before it's accepted for check-in? That is, if an
 Author: type field is defined, can check-ins of files lacking that
 field be blocked? 
Yes.
Like I wrote before; There is no need to rush this. Maybe you should talk
a bit with other projects that have their website under CVS.
Jan