* vc-hooks.el, vc.el: Move vc-directory-exclusion-list from vc.el
to vc-hooks.el so it will be available to other modes, such as
speedbar.el. Also, teach it to recognize monotine state directories.
* speedbar.el: Remove this mode's fragile assumptions about
version-control systems. Instead, make it use logic from
vc-hooks.el so it will become smarter whenever VC mode does.
* vc-hooks.el: 'added is a real state, not a future hypothetical
one. Fix the documentation.
Here are the guidelines for being an Emacs pretester.If you would like to do this, say so, and I'll add you tothe pretest list. Information for Emacs PretestersThe purpose of Emacs pretesting is to verify that the new Emacsdistribution, about to be released, works properly on your system *withno change whatever*, when installed following the preciserecommendations that come with the Emacs distribution.Here are some guidelines on how to do pretesting so as to make ithelpful. All of them follow from common sense together with thenature of the purpose and the situation.Please save this file, and reread it when a new series of pretestsstarts.* Get the pretest from gnu/emacs/pretest/emacs-MM.0.NN.tar.gzon alpha.gnu.org.* After a few days of testing, if there are no problems, please reportthat Emacs works for you and what configuration you are testing it on.* If you want to communicate with other pretesters, send mail toemacs-pretesters@gnu.org. I don't use that mailing list when I sendto you because I've found that mailing lists tend to amplify randomnoise into long discussions or even arguments, and that can waste alot of time. But when you have a reason to ask other pretesters forhelp, you can do it that way.* It is absolutely vital that you report even the smallest change ordeparture from the standard sources and procedure.Otherwise, you are not testing the same program that we asked you totest. Testing a different program is usually of no use whatever. Itcan even cause trouble, if you fail to tell us that you tested someother program instead of what we are about to release. We might thinkthat Emacs works, when in fact it has not even been tried, and mighthave a glaring fault.* Don't use a site-load.el file or a site-init.el file when you pretest.Using either of those files means you are not testing Emacs as a typicalsite would use it.Actually, it does no harm to test Emacs with such customizations *aswell as* testing it "out of the box". Anything you do that could finda bug is useful, as long as you make sure we know exactly what youdid. The important point is that testing with local changes is nosubstitute for testing Emacs exactly as it is distributed.* Even changing the compilation options counts as a change in theprogram. The Emacs sources specify which compilation options to use.Some of them are specified in makefiles, and some in machine-specificconfiguration files. They also give you ways to override this--but ifyou do, then you are not testing what ordinary users will do.Therefore, when pretesting, it is vital to test with the defaultcompilation options.(Testing with a different set of options can be useful *in addition*,but not *instead of* the default options.)* The machine and system configuration files of Emacs are parts ofEmacs. So when you test Emacs, you need to do it with theconfiguration files that come with Emacs.If Emacs does not come with configuration files for a certain machine,and you test it with configuration files that don't come with Emacs,this is effectively changing Emacs. Because the crucial fact aboutthe planned release is that, without changes, it doesn't work on thatmachine.To make Emacs work on that machine, we would need to install newconfiguration files. That is not out of the question, since it issafe--it certainly won't break any other machines that already work.But you will have to rush in the legal papers to give the FSFpermission to use such a large piece of text.* Look in the etc/MACHINES file.The etc/MACHINES file says which configuration files to use for yourmachine, so use the ones that are recommended. If you guess, you mightguess wrong and encounter spurious difficulties. What's more, if youdon't follow etc/MACHINES then you aren't helping to test that itsrecommendations are valid.The etc/MACHINES file may describe other things that you need to doto make Emacs work on your machine. If so, you should follow theserecommendations also, for the same reason.* Send your problem reports to emacs-pretest-bug@gnu.org, notbug-gnu-emacs.Sometimes we won't know what to do about a system-dependent issue, andwe may need people to say what happens if you try a certain thing on acertain system. When this happens, we'll send out a query.* Don't delay sending information.When you test on a system and encounter no problems, please report itright away. That way, we will know that someone has tested Emacs onthat kind of system.Please don't wait for several days "to see if it really works beforeyou say anything." Tell us right away that Emacs seems basically towork; then, if you notice a problem a few days later, tell usimmediately about that when you see it.It is okay if you double check things before reporting a problem, suchas to see if you can easily fix it. But don't wait very long. A goodrule to use in pretesting is always to report every problem on thesame day you encounter it, even if that means you can't find asolution before you report the problem.I'd much rather hear about a problem today and a solution tomorrowthan get both of them tomorrow at the same time.* Make each bug report self-contained.If you refer back to another message, whether from you or from someoneelse, then it will be necessary for anyone who wants to investigatethe bug to find the other message. This may be difficult, it isprobably time-consuming.To help save our time, simply copy the relevant parts of any previousmessages into your own bug report.In particular, if we ask you for more information because a bug reportwas incomplete, it is best to send me the *entire* collection ofrelevant information, all together. If you send just the additionalinformation, that makes extra work for us. There is even a risk thatwe won't remember what question you are sending the answer to.* When you encounter a bug that manifests itself as a Lisp error,try setting debug-on-error to t and making the bug happen again.Then you will get a Lisp backtrace. Including that in your bug reportis very useful.* For advice on debugging, see etc/DEBUG.* Debugging optimized code is possible, if you compile with GCC, butin some cases the optimized code can be confusing. If you are notaccustomed to that, recompile Emacs without -O. One way to do this is make clean make CFLAGS=-g* Configure tries to figure out what kind of system you have bycompiling and linking programs which calls various functions and looksat whether that succeeds. The file config.log contains any messagesproduced by compilers while running configure, to aid debugging ifconfigure makes a mistake. But note that config.cache reads:# Giving --cache-file=/dev/null disables caching, for debugging configure.or more simply,rm config.cache./configure* Don't try changing Emacs *in any way* during pretest unless it failsto work unchanged.* Always be precise when talking about changes you have made. Showthings rather than describing them. Use exact filenames (relative tothe main directory of the distribution), not partial ones. Forexample, say "I changed Makefile" rather than "I changed themakefile". Instead of saying "I defined the MUMBLE macro", send adiff.* Always use `diff -c' to make diffs. If you don't include context, itmay be hard for us to figure out where you propose to make thechanges. So we might ignore your patch.* When you write a fix, keep in mind that we can't install a changethat *might* break other systems without the risk that it will fail towork and therefore require an additional cycle of pretesting.People often suggest fixing a problem by changing config.h orsrc/ymakefile or even src/Makefile to do something special that aparticular system needs. Sometimes it is totally obvious that suchchanges would break Emacs for almost all users. We can't possiblymake a change like that. All we can do is ask you to find a fix thatis safe to install.Sometimes people send fixes that *might* be an improvement ingeneral--but it is hard to be sure of this. I can install suchchanges some of the time, but not during pretest, when I am trying toget a new version to work reliably as quickly as possible.The safest changes for us to install are changes to the s- and m-files. At least those can't break other systems.Another safe kind of change is one that uses a conditional to makesure it will apply only to a particular kind of system. Ordinarily,that is a bad way to solve a problem, and I would want to find acleaner alternative. But the virtue of safety can make it superior atpretest time.* Don't suggest changes during pretest to add features or makesomething cleaner. Every change risks introducing a bug, so I won'tinstall a change during pretest unless it is *necessary*.* If you would like to suggest changes for purposes other than fixinguser-visible bugs, don't wait till pretest time. Instead, send themafter we have made a release that proves to be stable. That is theeasiest time to consider such suggestions. If you send them atpretest time, we will have to defer them till later, and that mightmean we forget all about them.* In some cases, if you don't follow these guidelines, yourinformation might still be useful, but we would have to do more workto make use of it. That might cause it to fall by the wayside.Local Variables:mode: textEnd:# arch-tag: caf47b2c-b56b-44f7-a760-b5bfbed15fd3