Waldek Hebisch <[EMAIL PROTECTED]> writes: [...]
| Sorry, I do not get what you mean: | > Please let separate the patches: | | Do you mean that I should test and apply renaming patch without | removing 'util.ht'? I really do not like this -- that would mean | patching both copies or leaving a potential bug. That is a good point. | | > (1) one for renaming -- contains explanations | > (2) one for deletiing the redundant file -- also must contain | > explanation of why. | > | | So you want something like: | | : We messed up. We hade the rule: | : | : <old rule> | : | : We should not try to install two source files into single location, | : so we removed the rule. | | I find such "explanation" silly: we have version control and change | logs to keep history. And does not explain anything about the system | _after_ the fix is applied. 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. 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). You're making invaluable contributions to Axiom; let's make sure we don't end up in the same trap as current system. Thanks! -- Gaby _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
