On Tue, 28 Nov 2000, you wrote: > James A Sutherland wrote: > > > > > Putting a burden on the process of packaging the software for > > > distribution, solely so some files can be renamed. For this > > > reason and the effect on the repository, -1. > > > > I never suggested a vote on the issue; > > That's not a vote, it's a veto.
Which is even worse: you don't even appear to have considered the issue, yet you are leaping to a conclusion prematurely. > > you actually said that this is already done: "the documentation > > is packaged as part of the Apache distribution, with the SSIs > > statically 'compiled'". > > So foo.html looks the same whether you're looking at it on the > Apache site, a mirror, or your local installation, whether the > result is being produced with SSIs (the former two) or not (the > latter). Is this done, or not? First you said it is done - then one of the reasons you gave for the veto was that adding this step to building a release would be unnecessary extra work! Which is it? > > You've also missed the point completely - "solely so some files can > > be renamed"?! Renaming some of the files was part of the proposed > > method, not one of the aims. > > Chris wrote: > > Don't know, but if we do the switch by hand, I'd like to use > > .shtml or something instead of the .html to make headers & footers > > easier to distinguish. This may also make it easier to do the change > > over time -- header.shtml can be the newer larger header, and any > > hits on header.html in *.html are old files to fix. > > Perhaps I did miss the point. In which case I don't see what the > point actually is here. Chris? There is more to it than that: using a variable for part of header.*'s content implies that it must be .shtml (or use the x-bit kludge...) > > I don't see what you mean about "the effect on the repository", > > either: it's a simple change to the HTML files in it. > > Renaming files inside a repository creates headaches. Lots of > headaches. Big ones. Adding new files, as I now understand > Chris to be saying, doesn't create headaches, just possibly some > confusion. Rewriting the header and footer from a static HTML file to a dynamic SHTML file would seem like justification for adding the header.shtml file as a new file, and deleting the old one once no pages reference it. This could be regarded as a rename operation, but it is a case of "rename and replace contents". The phrase about 30 year old axes on their third handle and fifth head springs to mind! > > I accept it involves some extra work in packaging; if the CVS tree > > were made available, periodically updated, it would be a simple > > "wget" command to "freeze" the documentation for a release. > > Easily said, since you aren't one of the ones doing the packaging.. :-) Provided you have wget installed, and the docs are available online or on a server on your machine, it's a single command. If that's too much for everyone else, I would be quite happy to do the packaging myself... > > So put a link to a complete server with the docs on. > > No good. Lots of installations are done off-net or in intranets > w/o access. > > > Or "freeze" the docs from a server with SSI enabled. > > That's what's essentially done now, except it isn't done through > the Web, but by a script. Take a look at the 'how to roll a release' > document on dev.apache.org to see how it's currently done. I have. AFAICS, this is just a matter of replacing expand.pl with a suitable wget invocation, preceded with a cvs update in the appropriate directory. Same number of steps, no expand.pl needed any more. > In essence, I don't see any advantages here, and some disadvantages > for people who aren't on the docco project. But maybe I'm still > missing the point. Advantage: it works. Putting SSI commands in header.html won't work terribly well ATM. The x-bit kludge avoids this, but you're still replacing all the contents of that file - same axe, new handle, new head... James.
