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