Thanks for your hard work on this. APA> Do the manuals work for you? One quick lookup worked well for me. APA> Have you noticed any breakage in them? I got the wrong #tag URL in my browser (Mozilla) the first time, doing a reload in browser fixed it (thus it was not a typo in my entry). This is probably not an XEmacs-side problem (either network interruption or Mozilla screwage), but I mention it in case it comes up again. APA> The big questions I can't decide on are these: These are hard questions. For one thing, there should be only one manual source, and it should be keyed to versions internally (either some sort of ＠if, or in the text mentioning that the versions of XEmacs differ). But this is obviously a huge job. So we can't hold the web site responsbile for it. I would say the most generally useful would be the beta manuals. They probably describe gamma pretty accurately, in places more accurately than the gamma manuals do. They are also relatively likely to contain improvements in explanations and stuff. The organization stuff is web-maintainer specific. My feeling is that if we end up with more than one set of manuals on line, the published URLs should be minor-version specific (eg, 21.1, 21.4), and the symbolic tags (stable, gamma) should be mentioned only in the index.html. That way the URLs stay stable with new releases. The exception is "beta" instead of "21.5", the latter would get renamed upon release, which is icky, and using "beta" properly reflects the continuity of the trunk. That is, at release of 21.5, beta gets _cloned_, not _moved_, to 22.0. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

Hi Jarl! Jarl> On 14 Dec 2001, Adrian Aichner wrote: Jarl> [] Jarl> Yes. Good. I have linklinted them, so they better work :-) Jarl> I just wondering about the strange chapter/section numbering: Jarl> XEmacs user's manual: Jarl> 3.2 Command Line Switches and Arguments Jarl> 3.3 How XEmacs finds Directories and Files Jarl> 22.8 Packages Jarl> What a jump? Ah, yes, I saw that. I'll have to track that down. Nothing that I caused, I would hope :-) Jarl> My opinion: For every stable major.minor *and* the latest Jarl> (unstable) beta Every stable could expand to 19.0 .. 21.1, a long list, a lot of disk, very little value. I think we need a old-documentation-removal-criterion. Vin, what are your thought on this? How about most recent stable version only? Jarl> Both, but use symbolic names when making links, that would Jarl> be easier to bookmark, and refer to from other HTML Jarl> documents, but store them in version directories, that also Jarl> makes it possible to link to specific versions. I do now understand this. Please give examples. What I was getting at was that you need to write down a date for every http://www.xemacs.org/Documentation/beta/... link you put somewhere. All those links have builtin expiry dates. http://www.xemacs.org/Documentation/21.1/... is specific, only the link may point nowhere after its manuals are removed form the website after 21.4 is stable and put up instead. Note how 21.1, 21.4, 21.5 will be available along time, when referred to that way, as they go to the motions (beta, gamma, stable). I think beta, gamma, stable are convenient entry points to access these at a given date. When pointing to these for discussion or advice on mailing lists one would be well advises to use specific version numbers instead. One could say: You will always find the docs for the current beta release in http://www.xemacs.org/Documentation/beta/... To see how new feature is used, refer to http://www.xemacs.org/Documentation/21.1/html/xemacs.html#SOMETHING Jarl> The editor is unchanged (with respect to features) among Jarl> patch-numbers, so with that in mind major.minor should be Jarl> enough for documentation, but then again bugs are fixed in Jarl> documentation too from patch-number to patch-number. But for Good, I think we have agreement on this. Jarl> online it makes no sense to have other than the latest Jarl> patch-number available. Thanks, Jarl! Jarl> Jarl -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Hi. On 15 Dec 2001, Adrian Aichner wrote: [] So, who cares about disk space these days. In Denmark virtually every ISP seem to give users unlimited disk-space for their homepage. I use that for backup of my workstation in a non-accessible directory ;-) If so, the ones who have opinions about diskspace should set these criterias. I wish the following URLS would be valid: http://www.xemacs.org/Documentation/beta/ http://www.xemacs.org/Documentation/gamma/ http://www.xemacs.org/Documentation/21.4/ http://www.xemacs.org/Documentation/stable/ http://www.xemacs.org/Documentation/21.1/ and stable versionnumbers back as fas as diskspace allows I don't consider it relevant to have versionnumber-urls for beta releases (but it doesn't hurt) [] Agree, I think we agree pretty much. Actually from the stable change policiy: We undertake to make no changes to the stable code that are not absolutely required to fix critical bugs that can cause data loss (including crashes, which can always destroy data) or open security holes. One can conclude documentation is constant through *all* patch-numbers(I haven't checked if it holds), so our discussion is irelevant for stable versions at least. Regarding which packages texi manuals should be online I don't know how much manual work it costs, but in general I think those who care of diskspace should make a decision here too. Jarl

Valdis> On Sat, 15 Dec 2001 12:16:54 +0100, Jarl Friis said: Valdis> It's not just diskspace. Valdis> It's bandwidth too. I have a pair of Dell systems, one at And tape backup is still expensive! Are real big sites still doing these? Valdis> work and one at home. The work system runs the Valdis> latest-and-greatest everything, because it's Valdis> well-connected network-wise. On the other hand, updating Valdis> stuff on my home machine means either sucking huge files Valdis> over a 56k modem or physically carting the machine to my Valdis> office and borrowing a network drop to download stuff. Valdis> -r--r--r-- xemacadm 10469429 Sep 7 12:20 xemacs-21.5.3.tar.gz Valdis> -rw-r--r-- youngs 3787011 Sep 29 11:39 xemacs-mule-sumo-2001-09-29.tar.bz2 Valdis> -rw-r--r-- youngs 14515329 Sep 29 13:17 xemacs-sumo-2001-09-29.tar.bz2 Valdis> That's 28,771,769 bytes - or about 95 minutes to download Valdis> over a 56K modem. Valdis> That's not so bad - but it starts to add up pretty quickly Valdis> as more packages start taking this "XYZ is cheap" Valdis> attitude. Hi Valdis, I have just added rules to xemacs/man/Makefile which allow you to build html from texi source, provided you have texi2html installed. See http://texi2html.cvshome.org/servlets/ProjectSource The XEmacs Website uses that new feature. See xemacsweb/Documentation/Makefile how it cvs exports just xemacs/man and builds the online docs from it. XEmacs developers won't have to download bigger tarballs, no matter for how many XEmacs releases we provide online docs for at http://www.xemacs.org. I am convinced that putting up currently stable, gamma, and beta docs will be all we'll ever need. Actually, Valdis, you could do me a favor. How do the online docs in http://www.xemacs.org/Documentation/ perform for you? Some data would be great. Use any XEmacs web mirror you like. How well is http://www.xemacs.org/Documentation/beta/html/xemacs.html coming across? http://www.xemacs.org/Documentation/beta/html/xemacs_30.html is the biggest file. How bad is that one? Thanks in advance, Adrian Valdis> I'd not be flaming, except I spent *way* too long the Valdis> other night downloading Mozilla. And before you ask - no, Valdis> DSL and cablemodem are *NOT* available in my neighborhood Valdis> yet. Valdis> /Valdis (who once managed to work quite effectively over a Valdis> 300 baud modem ;) -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

APA> OK, Martin felt that way too when I asked this a while back. APA> For our users I would bet that latest stable would be more APA> useful. Stephen> FWIW, I tend to disagree. In particular this serves the Stephen> people _considering_ gamma very badly, no online docs for Stephen> the new features (widgets, netinstaller, etc). [NB, this Stephen> presumes only one set of manuals. There is no problem if Stephen> we have stable and beta.] Our marketing guys need to provide us with some user-base data, showing their distribution across stable, gamma, and beta. I assume stable will be the fat rabbit. Stephen> in places more accurately than the gamma manuals do. Stephen> They are also relatively likely to contain improvements Stephen> in explanations and stuff. APA> How about currently stable and beta, then? Stephen> I think that's probably sufficient. If we start feeling Stephen> the need for gamma docs, that means gamma has gone for Stephen> much too long. :-) ... but it can easily be added, if necessary. APA> I though of physically storing manuals under APA> Documentation/{21.1,21.4,21.5} and switching around symlinks APA> to them. Stephen> This works well for Stephen> stable -> 21.1 Stephen> gamma -> 21.4. Stephen> Now promote 21.4: Stephen> stable -> 21.4 Stephen> gamma -> there_currently_is_no_gamma_branch.html OK, we can write this document in no time. Stephen> And people who have stale 21.1 URLs can still access it Stephen> unless we remove the docs for diskspace reasons. But if Stephen> we have Stephen> beta -> 21.5 Stephen> And we release a gamma, say 22.0, we now want Stephen> gamma -> 22.0 Stephen> beta -> 22.1 Stephen> We must clone the tree at this point, because gamma and Stephen> beta will now diverge (rapidly, we hope :-). Note that Stephen> either the 21.5 URL dangles, or we _further_ clone a 21.5 Stephen> branch for historical purposes. We might actually like Stephen> to do That's where you lose me. I am assuming docs reside physically under their major.ninor directory. That leaves no questions open, right? Stephen> 21.5 -> 21.5_has_forked_into_22.0_gamma_and_22.1_beta.html. Huh? Stephen> True, all of the physical manipulations are basically the Stephen> same. However using 21.5 -> beta is better IMO because Stephen> it emphasizes the continuity of the trunk and is Stephen> conceptually cleaner. Note that we don't know what a What I don't like about this is that beta URLs have a built-in expiry date. A 21.1 doc URL will remain meaningful forever, even if we zap the files. People will always know what there are looking at (or are missing). Stephen> user means when he asks for "21.5" at this point in time. Stephen> He might mean "I've upgraded to gamma, give me 22.0" or Stephen> he might mean "I'm on the bleeding edge, 22.1". Yeah, that's why I would like to stick with the numbers and only provide the stable, gamma, beta links as entry points. People click beta and find that it's currently pointing to 21.5. Stephen> -- Stephen> Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Stephen> Don't ask how you can "do" free software business; Stephen> ask what your business can "do for" free software. -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

I didn't pay close attention to this thread, but I would assume that links for stable and beta would be enough. There should also be links referenced by name (ie 21.1 or 21.4) as long as we have enough disk space, but I don't see any reason to have these explicitly called out on the webpage. Stable would point at 21.1 at this moment, and would move to 21.4 RSN. Beta would point to 21.5. That's how I see things, anyway. - vin "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: