> Not because you can come up with a silly explanation means that any
> explanation should be silly. Please, let's keep things in perspective.
>
> What about:
>
> There are two files for each (special) character glyph, one
> for the upper case form, and one for the lower case form.
> Historically, the names for these files used to differ only in the
> first character (which is upper case for the upper case form).
> That was non-portable and caused griefs on brain damaged file
> systems that identify themselves as ``case preserving, case insensitive''
> where alpha.ps and Alpha.ps ended up designating the same file.
> Consequently, the files for the upper case form have been renamed
> to xxx-cap.ps, where "xxx" used to be the historic name.
>
> ?
>
> Please feel free to elaborate/improve it.
>
Gaby, we are miscomunicating here. I wrote about 2006-11/msg00294
for which _really_ I that best explantion is "remove reference to
redundant file" (and ChangeLog is _the_ place to put it).
Expanation you wrote is about 2006-11/msg00297 (you wrote that it
contains explanation, but in fact explanantion is in the text
outside the patch). Again ChangeLog is logical place to put
it. If you insist on some info outside ChangeLog i would
propose to create a new pamplets called "Coding guide" (or
maybe into DeveloperNotes).
>
> I'm of the opinion that you get should in the habit of including
> explanation in the pamphlets when you submit them for consideration.
> I would like to see the changes explained. One reason, in this
> particular case, is that when it comes to merge build-improvements
> back to trunk (whatever it is called) there will be differences and
> conflicts, and I would hate to have to spend hours in front of a
> browser digging in the archive. Yes, we have ChangeLog files, but
> they are no substitute for documentation files (which are the pamphlets).
>
Well:
1) AFAIU the whole SCM discussion started because we wanted chageset
support. ChangeLog entry is part of a chageset and would be the
first place I would look at during merge.
2) I you are concerned that ChangeLog is not a pamphlet we can easily
correct this: write a few Latex macros, header and footer. Then
a little script can easily convert format (bidirectionally if
for some reason we also want conventional ChangeLog).
I think we have conflicting paradigms here. I belive that history
has place in documentation only if it explains _significant_ aspect
of current system. In case of current filename change past status
really tells you nothing about new system.
--
Waldek Hebisch
[EMAIL PROTECTED]
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
