Jan> I can guess why having multiple people hack on it randomly Jan> will cause problems. But how does CVS do so? Doesn't that depend on how many people have CVS commit access? We're not talking about making the Web site publically writable. I think a reasonable thing to do would be to include the Webmaster on the Review Board, add general responsibility for documentation to his portfolio, and help him find volunteers to do those parts of the documentation he didn't volunteer to do. (The reason for doing this is to have somebody who will yell about changes to the docs that screw his stuff up.) And he can add a couple of team members as he likes as Web staff (who would not be review board members). And maybe the "last patch wins" rule should be removed for the Web site ;-) Jan> First of all CVS will make your access problem easier: You Jan> just edit the stuff locally and CVS will take care of what Jan> needs go to the site. More importantly, CVS is designed for Jan> group collaboration, that means that you can see _what_ is Jan> changed and by who. Yes, I wonder about whether it will cause drag on design operations. Remember, XEmacs's directory structure changes only slowly, but we can expect that the Web site's directory structure will change fairly often, at least for a while. I have tried moving directories in CVS, and I've discovered that (for me) past a certain, fairly small, point deleting the current module and creating a new one is the easiest way to go. That's a lot of extra work. Is this not true? Jan> Yes, but our current problem is (or better was) one of Jan> content, I can write all the READMEs , installation notes, Jan> little items telling people there is know problem with Jan> version so-and-so of the mule-base package but I have no way Jan> of getting it to the site. That's true for review board members; but the rest of us will still be limited to xemacs-patches (or something equivalent? webmaster(a)xemacs.org?), I presume. One of the points of CVS is that if you (as Webmaster) do move a file, CVS will tell other authorized users, mostly the Review Board, that you have moved the file. A CVS wizard could set it up so that nobody but the Web maintainer could move files, I believe. Only the Web maintainer should be allowed to do that kind of thing, of course. Jan> Well, I respect your opinion and I promise to leave you alone Jan> while you do your work. However when your work has stabilized Jan> I would like you to consider a solution that allows multiple Jan> people to work on the website, if need be[1]. A solution that Jan> no longer makes the maintenance[2] of the website dependent Jan> on one (or a few) persons time. For me such a solution is Jan> CVS, it isn't perfect but we already have the infra structure Jan> in place. Jan> Footnotes: [1] I am not claiming this should be the normal Jan> mode of operation. I would go the opposite direction. Under normal circumstances, everybody with CVS commit access to the sources should have equivalent access to the Web site. Eg, someone who maintains packaged Lisp should have check-in access to a set of pages (possibly a subdirectory, depending on how tight artistic control the Webmaster wants to maintain) devoted to the package they maintain. Maintainers of binary kits might also have their own pages. But when a design or organization overhaul is being done, the web maintenance team should be left alone until they're done (or done in for taking too long...). 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 think CVS will help enforce this, as mentioned above. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."