[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] A wekly reminder?!
From: |
Jim Segrave |
Subject: |
Re: [Bug-gnubg] A wekly reminder?! |
Date: |
Fri, 8 Aug 2003 16:39:48 +0200 |
User-agent: |
Mutt/1.4.1i |
Slightly expanded for people's perusal
1. Subscription
You may always change your subscribtion options at
http://mail.gnu.org/mailman/listinfo/bug-gnubg. This is also the
place for unsubscribing.
2. Subject
Please use a meaningful subject. It is not helpful to use " bug
found" or "gnubg" as a subject. If you really want to be smart put
something like:
bug:
feature request:
position:
documentation:
compiling error:
or a similar meaningful categoray at the front of your subject.
For example:
Subject: bug: gnubg crashes when loading Snowie .mat file
3. Bug reports
Much as the devopers would like to see nothing but praise and
astonishment from the users, bugs do occur and they form one of the
main purposes of this list. A good bug report makes it much easier
for a developer to find and (one hopes) fix a problem. What's
needed:
A. Which software you are running:
You need to report what version of gnubg you are running and the
date on which it was built - gnubg changes rapidly and your bug may
already have been reported and fixed. So please give some
information like:
gnubg 0.14-devel built on 2003/07/25 running on Windows XP
Click on the Help button on the board to get a pop-up with the
'gnubg 0.14-devel' or whatever. Your system should be able to tell
you the date of the main file - gnubg.exe (Windows) or just plain
gnubg (Unix/Linux). It helps to know if you are running a Windows
machine, a Mac, a Linux or another Unix system. While the source
code for gnubg is the "same" for each system, there are differences
and some bugs only show up on one or another platform.
Usually there's little point in giving a hardware description unless
it's likely to be directly relevant to your problem. So if you are
having display corruption problems or sound problems you might want
to give a brief overview of your hardware.
B. A short description of the problem. Try to keep it brief, but not
at the expense of improtant information. If gnubg crashes when you
do something, then if there's an error message, the developer's want
to know what the message said. If there is no error message, that's
relevant as well. What is not helpful is being told "When I do this
and that, the program prints some kind of error message and then exits".
Be sure to include why you think it's a problem. Sometimes it's
obviously wrong - gnubg crashes or locks up and won't do anything
further. But some bug reports are questions about gnubg's evaluation
of a position and it may be that you simply didn't realise why it's
probably the correct evaluation (forgetting about the Jacoby rule,
failing to notice your opponent already has a man off, so you won't
get a gammon/backgammon, not realising how likely you are to be
doubled out on the next move, etc. Don't worry about making a
mistake in public, various developers have made all of the previous
mistakes before.
Along with all this it helps to know if the problem 1) happens every
time you do some particular thing or 2) happens every once in a
while but always when you've performed some particular action or 3)
seems to happen with no apparent pattern.
C. If at all possible, give a simple way of seeing the problem you
are reporting. For example, giving a matchid and position ID (they
are displayed on the board), then telling us what move you made
which caused the problem makes it easy for someone to repeat the
problem and find the cause. Sometimes this isn't possible, but when
it is it makes getting a bug fixed *many* times easier.
D. There are some cases where the only way to really illustrate the
problem is to examine a full match file or a large output file such
as an entire game in HTML. In those cases, please don't post the
match or HTML file to the list, describe the problem and expect that
one or more developers will ask you to mail them a copy privately.
4. Formatting
Please don't send HTML e-mails. Many readers of this list use
mail-clients which don't support HTML mail. Some may use anti-spam
filters which reject all mail which is in HTML, so they'll never
even have a chance to see what you have to say.
A few e-mail programs like Outlook Express send HTML by default (or
send a copy in plain text and a second copy in HTML)It's easy to
change this in the option menu.
Use the enter key to wrap lines at no more then 75 characters. This
helps other readers whose mail client may not wrap lines and also
makes it easier to quote your text when replying.
5. Signature
Your signature should begin with a line on its own containing only
two hyphens (minus signs) followed by a space. Good mail clients
will recognise this as the start of the signature and will
automatically remove the signature when composing a reply
After that line, your signature should not be more than four more
lines of text.
For example:
--
The world is so full of a number of things
I'm sure we could all be as happy as kings
And you know how happy kings are' James Thurber
Al Fansome (address@hidden) www.gnubg.org
If you quote another posting, it's _not_ necessary to quote the
signature also.
Do *not* include graphics, logos, pictures or other strange images
as part of your signature.
6. Quoting
The object of quoting is to make it possible for a reader to see an
exchange of e-mails as though they were listening to a
conversation. The reader should normally not need to go back and
read a previous e-mail to see what point you are replying to, nor
should they need to scroll backwards and forwards in your e-mail to
find the different parties to a conversation.
Ideally when responding to someone else's e-mail, you should quote
only enough of that person's e-mail to let the reader know *what* the
other person wrote that you are responding to. Remove any other text
that isn't relevant to your reply. Some topics can develop into threads
of 10 or more e-mails and no-one wants to read the same irrelevant
portions 10 times while following the thread.
If you are responding to more than one topic in someone else's
e-mail, then quote each of those topics separately and put your
responses immediately below the associated topic.
Please avoid top quouting and full qouting. What do we mean? A few
MS Windows e-mail programs (like Outlook Express) always quote the
original e-mail in full at the bottom of the reply and put your
cursor at the top when you begin composing a reply. The result is
referred to as top quoting - all the responses come at the top and
the reader has to scroll down to see what it is you are replying
to. Failure to remove those portions of the original e-mail to which
you are not replying is referred to as full quoting. In the worst
case, a lengthy exchange of e-mails could end up with 10 or 15
copies of the original e-mail. Top quoting and full quoting from some
of the most annoying behaviours in mailing lists.
With "good" quoting you will greatly enhance the readibility of your
e-mail. Here is an example of qouting as it should be done:
| Adam wrote:
|
| Here is a bunch of text by someone. This was originally a 25 line
| paragraph, but [snip irrelevant portion]
|
| Now you, as the author, respond to those points, right here.
| If you have more to quote, do so:
|
| Someone still had a couple more points to which you wanted to
| reply, so you quote them [but still snip unneded stuff]
|
| and respond to it.
|
| Your sig then typically follows (but DON'T quote Someone's sig,
| unless that is what you are responding to... and if so, you'd better
| make sure that it is relevant to this mailing list, or that it
| is a miniscule fraction of your otherwise completely on-topic post.)
When you answer to a posting, please use _always_ the "reply" or
"reply to list" button. This will keep a thread readable like
| ---- original posting A
| -------| direct answer to A (B)
| ---------------direct answer to B (C)
| --------------------| direct answer to C
| -------| direct answer to A (D)
| ----------------direct answer to D
7. Attachments
No. Don't send attached files to this mailing list. Exception: You may
be asked to do so (mostly in a direct e-mail, very seldom to this mailing
list.
--
Jim Segrave address@hidden