Stephen> Thanks for your hard work on this. APA> Do the manuals work for you? Stephen> One quick lookup worked well for me. APA> Have you noticed any breakage in them? Stephen> I got the wrong #tag URL in my browser (Mozilla) the Stephen> first time, doing a reload in browser fixed it (thus it Stephen> was not a typo in my entry). This is probably not an Stephen> XEmacs-side problem (either network interruption or Stephen> Mozilla screwage), but I mention it in case it comes up Stephen> again. OK, thanks. APA> The big questions I can't decide on are these: Stephen> These are hard questions. For one thing, there should be Stephen> only one manual source, and it should be keyed to Stephen> versions internally (either some sort of ＠if, or in the Stephen> text mentioning that the versions of XEmacs differ). But Stephen> this is obviously a huge job. So we can't hold the web Stephen> site responsbile for it. Phui, you almost scared me! Stephen> I would say the most generally useful would be the beta Stephen> manuals. They probably describe gamma pretty accurately, OK, Martin felt that way too when I asked this a while back. For our users I would bet that latest stable would be more useful. Stephen> in places more accurately than the gamma manuals do. Stephen> They are also relatively likely to contain improvements Stephen> in explanations and stuff. How about currently stable and beta, then? If we start feeling the need, we can still add gamma for increased lifetime of the docs (beta -> gamma -> stable). Stephen> The organization stuff is web-maintainer specific. My Stephen> feeling is that if we end up with more than one set of Stephen> manuals on line, the published URLs should be Stephen> minor-version specific (eg, 21.1, 21.4), and the symbolic Stephen> tags (stable, gamma) should be mentioned only in the Stephen> index.html. That way the URLs stay stable with new Stephen> releases. Good, we agree. Stephen> The exception is "beta" instead of "21.5", the latter The former or the latter? Stephen> would get renamed upon release, which is icky, and using Stephen> "beta" properly reflects the continuity of the trunk. Stephen> That is, at release of 21.5, beta gets _cloned_, not Stephen> _moved_, to 22.0. I though of physically storing manuals under Documentation/{21.1,21.4,21.5} and switching around symlinks to them. Please explain more if I didn't seem to catch your drift here. Thanks, Stephen, for the feedback! Adrian 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/

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:

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/

On Sat, 15 Dec 2001 12:16:54 +0100, Jarl Friis said: It's not just diskspace. It's bandwidth too. I have a pair of Dell systems, one at work and one at home. The work system runs the latest-and-greatest everything, because it's well-connected network-wise. On the other hand, updating stuff on my home machine means either sucking huge files over a 56k modem or physically carting the machine to my office and borrowing a network drop to download stuff. -r--r--r-- xemacadm 10469429 Sep 7 12:20 xemacs-21.5.3.tar.gz -rw-r--r-- youngs 3787011 Sep 29 11:39 xemacs-mule-sumo-2001-09-29.tar.bz2 -rw-r--r-- youngs 14515329 Sep 29 13:17 xemacs-sumo-2001-09-29.tar.bz2 That's 28,771,769 bytes - or about 95 minutes to download over a 56K modem. That's not so bad - but it starts to add up pretty quickly as more packages start taking this "XYZ is cheap" attitude. I'd not be flaming, except I spent *way* too long the other night downloading Mozilla. And before you ask - no, DSL and cablemodem are *NOT* available in my neighborhood yet. /Valdis (who once managed to work quite effectively over a 300 baud modem ;)