From 3c42d11863f51a4ab66752e90bf6a11013580875 Mon Sep 17 00:00:00 2001 From: simon Date: Sun, 16 Dec 2001 14:56:02 +0000 Subject: [PATCH] Add two extra appendices giving the licence text and details of how to give feedback. (I think the latter has suddenly become worthwhile now we have the ability to distribute a help file; so people won't have to come to the website for the feedback information.) git-svn-id: svn://svn.tartarus.org/sgt/putty@1502 cda61777-01e9-0310-a592-d414129be87e --- doc/Makefile | 3 +- doc/blurb.but | 7 +- doc/feedback.but | 281 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ doc/licence.but | 27 ++++++ 4 files changed, 314 insertions(+), 4 deletions(-) create mode 100644 doc/feedback.but create mode 100644 doc/licence.but diff --git a/doc/Makefile b/doc/Makefile index 0c8a661c..a7e1868e 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -1,4 +1,5 @@ -CHAPTERS = blurb intro gs using config pscp psftp plink pubkey pageant faq +CHAPTERS := blurb intro gs using config pscp psftp plink pubkey pageant +CHAPTERS += faq feedback licence INPUTS = $(patsubst %,%.but,$(CHAPTERS)) diff --git a/doc/blurb.but b/doc/blurb.but index e4491e93..99b1b1be 100644 --- a/doc/blurb.but +++ b/doc/blurb.but @@ -14,7 +14,8 @@ client. This manual documents PuTTY, and its companion utilities PSCP, Plink, Pageant and PuTTYgen. -\copyright Copyright 2001 Simon Tatham. All rights reserved. You may -distribute this documentation under the MIT licence. +\copyright This manual is copyright 2001 Simon Tatham. All rights +reserved. You may distribute this documentation under the MIT +licence. See \k{licence} for the licence text in full. -\versionid $Id: blurb.but,v 1.4 2001/11/25 17:05:01 simon Exp $ +\versionid $Id: blurb.but,v 1.5 2001/12/16 14:56:02 simon Exp $ diff --git a/doc/feedback.but b/doc/feedback.but new file mode 100644 index 00000000..d1ef1e3d --- /dev/null +++ b/doc/feedback.but @@ -0,0 +1,281 @@ +\versionid $Id: feedback.but,v 1.1 2001/12/16 14:56:02 simon Exp $ + +\A{feedback} Feedback and bug reporting + +This section describes what to do if you want to contact the PuTTY +development team. + +\K{feedback-general} gives some general guidelines for sending any +kind of e-mail to the development team. Following sections give more +specific guidelines for particular types of e-mail, such as bug +reports and feature requests. + +\H{feedback-general} General guidelines + +The PuTTY development team gets a \e{lot} of mail. If you can +possibly solve your own problem by reading the manual, reading the +FAQ, reading the web site, asking a fellow user, perhaps posting on +the newsgroup \W{news:comp.security.ssh}\c{comp.security.ssh}, or +some other means, then it would make our lives much easier. + +If the volume of e-mail really gets on top of us and we can't find +time to answer it all, then the first e-mails we discard will be the +ones from people who don't look as if they have made a reasonable +effort to solve their own problems. This is not intended to cause +offence; it's occasionally a necessary response to a serious +problem. We get a \e{lot} of e-mail. Really. + +Also, the PuTTY contact email address is a mailing list. For this +reason, e-mails larger than 40Kb will be held for inspection by the +list administrator, and will not be allowed through unless they +really appear to be worth their large size. Therefore: + +\b Don't send your bug report as a Word document. Word documents are +roughly fifty times larger than writing the same report in plain +text. In addition, most of the PuTTY team read their e-mail on Unix +machines, so copying the attachment to a Windows box to run Word is +very inconvenient. Not only that, but several of us don't even +\e{have} a copy of Word! + +\b Don't mail large screen shots without checking with us first. +Sending a screen shot of an error box is almost certainly +unnecessary when you could just tell us in plain text what the error +was. Sending a full-screen shot is sometimes useful, but it's +probably still wise to check with us before sending it. + +\b If you want to send us a screen shot, or any other kind of large +data file, it is much more convenient for us if you can put the file +on a web site and send us the URL. That way (a) we don't have to +download it at all if it doesn't look necessary; and (b) only one +member of the team needs to download it, instead of it being +automatically sent to everyone on the mailing list. + +\b If you \e{must} mail a screen shot, don't send it as a \cw{.BMP} +file. \cw{BMP}s have no compression and they are \e{much} larger +than other image formats such as PNG, TIFF and GIF. Convert the file +to a properly compressed image format before sending it. + +\H{feedback-bugs} Reporting bugs + +If you think you have found a bug in PuTTY, your first steps should +be: + +\b Check the +\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist.html}{Wishlist +page} on the PuTTY website, and see if we already know about the +problem. If we do, it is almost certainly not necessary to mail us +about it, unless you think you have extra information that might be +helpful to us in fixing it. (Of course, if we actually \e{need} +specific extra information about a particular bug, the Wishlist page +will say so.) + +\b Check the +\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html}{Change +Log} on the PuTTY website, and see if we have already fixed the bug +in the development snapshots. + +\b Check the +\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html}{FAQ} +on the PuTTY website (also provided as \k{faq} in the manual), and +see if it answers your question. The FAQ lists the most common +things which people think are bugs, but which aren't bugs. + +\b Download the latest development snapshot and see if the problem +still happens with that. This really is worth doing. As a general +rule we aren't very interested in bugs that appear in the release +version but not in the development version, because that usually +means they are bugs we have \e{already fixed}. On the other hand, if +you can find a bug in the development version that doesn't appear in +the release, that's likely to be a new bug we've introduced since +the release and we're definitely interested in it. + +If none of those options solved your problem, and you still need to +report a bug to us, it is useful if you include some general +information: + +\b Tell us what version of PuTTY you are running. To find this out, +use the "About PuTTY" option from the System menu. Please \e{do not} +just tell us \q{I'm running the latest version}; e-mail can be +delayed and it may not be obvious which version was the latest at +the time you sent the message. + +\b Tell us what version of what OS you are running PuTTY on. + +\b Tell us what protocol you are connecting with: SSH, Telnet, +Rlogin or Raw mode. + +\b Tell us what kind of server you are connecting to; what OS, and +if possible what SSH server (if you're using SSH). You can get some +of this information from the PuTTY Event Log (see \k{using-eventlog} +in the manual). + +\b Send us the contents of the PuTTY Event Log, unless you +have a specific reason not to (for example, if it contains +confidential information that you think we should be able to solve +your problem without needing to know). + +\b Try to give us as much information as you can to help us +see the problem for ourselves. If possible, give us a step-by-step +sequence of \e{precise} instructions for reproducing the fault. + +\b Don't just tell us that PuTTY \q{does the wrong thing}; tell us +exactly and precisely what it did, and also tell us exactly and +precisely what you think it should have done instead. Some people +tell us PuTTY does the wrong thing, and it turns out that it was +doing the right thing and their expectations were wrong. Help to +avoid this problem by telling us exactly what you think it should +have done, and exactly what it did do. + +\b If you think you can, you're welcome to try to fix the problem +yourself. A patch to the code which fixes a bug is an excellent +addition to a bug report. However, a patch is never a \e{substitute} +for a good bug report; if your patch is wrong or inappropriate, and +you haven't supplied us with full information about the actual bug, +then we won't be able to find a better solution. + +\b +\W{http://www.chiark.greenend.org.uk/~sgtatham/bugs.html}\cw{http://www.chiark.greenend.org.uk/~sgtatham/bugs.html} +is an article on how to report bugs effectively in general. If your +bug report is \e{particularly} unclear, we may ask you to go away, +read this article, and then report the bug again. + +\H{feedback-features} Requesting extra features + +If you want to request a new feature in PuTTY, the very first things +you should do are: + +\b Check the +\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist.html}{Wishlist +page} on the PuTTY website, and see if your feature is already on +the list. If it is, it probably won't achieve very much to repeat +the request. (But see \k{feedback-feature-priority} if you want to +persuade us to give your particular feature higher priority.) + +\b Check the +\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html}{Change +Log} on the PuTTY website, and see if we have already added your +feature in the development snapshots. If it isn't clear, download +the latest development snapshot and see if the feature is present. +If it is, then it will also be in the next release and there is no +need to mail us at all. + +If you can't find your feature in either the development snapshots +\e{or} the Wishlist, then you probably do need to submit a feature +request. Since the PuTTY authors are very busy, it helps if you try +to do some of the work for us: + +\b Do as much of the design as you can. Think about \q{corner +cases}; think about how your feature interacts with other existing +features. Think about the user interface; if you can't come up with +a simple and intuitive interface to your feature, you shouldn't be +surprised if we can't either. Always imagine whether it's possible +for there to be more than one, or less than one, of something you'd +assumed there would be one of. (For example, if you were to want +PuTTY to put an icon in the System tray rather than the Taskbar, you +should think about what happens if there's more than one PuTTY +active; how would the user tell which was which?) + +\b If you can program, it may be worth offering to write the feature +yourself and send us a patch. However, it is likely to be helpful +if you confer with us first; there may be design issues you haven't +thought of, or we may be about to make big changes to the code which +your patch would clash with, or something. If you check with the +maintainers first, there is a better chance of your code actually +being usable. + +\H{feedback-feature-priority} Requesting features that have already +been requested + +If a feature is already listed on the Wishlist, then it usually +means we would like to add it to PuTTY at some point. However, this +may not be in the near future. If there's a feature on the Wishlist +which you would like to see in the \e{near} future, there are +several things you can do to try to increase its priority level: + +\b Mail us and vote for it. (Be sure to mention that you've seen it +on the Wishlist, or we might think you haven't even \e{read} the +Wishlist). This probably won't have very \e{much} effect; if a huge +number of people vote for something then it may make a difference, +but one or two extra votes for a particular feature are unlikely to +change our priority list immediately. Also, don't expect a reply. + +\b Offer us money if we do the work sooner rather than later. This +sometimes works, but not always. The PuTTY team all have full-time +jobs and we're doing all of this work in our free time; we may +sometimes be willing to give up some more of our free time in +exchange for some money, but if you try to bribe us for a \e{big} +feature it's entirely possible that we simply won't have the time to +spare - whether you pay us or not. (Also, we don't accept bribes to +add \e{bad} features to the Wishlist, because our desire to provide +high-quality software to the users comes first.) + +\b Offer to help us write the code. This is probably the \e{only} +way to get a feature implemented quickly, if it's a big one that we +don't have time to do ourselves. + +\H{feedback-webadmin} Web server administration + +If the PuTTY web site is down (Connection Timed Out), please don't +bother mailing us to tell us about it. Most of us read our e-mail on +the same machines that host the web site, so if those machines are +down then we will notice \e{before} we read our e-mail. So there's +no point telling us our servers are down. + +Of course, if the web site has some other error (Connection Refused, +404 Not Found, 403 Forbidden, or something else) then we might +\e{not} have noticed and it might still be worth telling us about it. + +\H{feedback-permission} Asking permission for things + +PuTTY is distributed under the MIT Licence (see \k{licence} for +details). This means you can do almost \e{anything} you like with +our software, our source code, and our documentation. The only +things you aren't allowed to do are to remove our copyright notices +or the licence text itself, or to hold us legally responsible if +something goes wrong. + +So if you want permission to include PuTTY on a magazine cover disk, +or as part of a collection of useful software on a CD or a web site, +then \e{permission is already granted}. You don't have to mail us +and ask. Just go ahead and do it. We don't mind. + +If you want to use parts of the PuTTY source code in another +program, then it might be worth mailing us to talk about technical +details, but if all you want is to ask permission then you don't +need to bother. You already have permission. + +\H{feedback-mirrors} Mirroring the PuTTY web site + +All mirrors of the PuTTY web site are welcome. Please don't bother +asking us for permission before setting up a mirror. You already +have permission. We are always happy to have more mirrors. + +If you mail us \e{after} you have set up the mirror, and remember to +let us know which country your mirror is in, then we'll add it to +the +\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/mirrors.html}{Mirrors +page} on the PuTTY website. + +If you have technical questions about the process of mirroring, then +you might want to mail us before setting up the mirror; but if you +just want to ask for permission, you don't need to. You already have +permission. + +\H{feedback-compliments} Praise and compliments + +One of the most rewarding things about maintaining free software is +getting e-mails that just say \q{thanks}. We are always happy to +receive e-mails of this type. + +Regrettably we don't have time to answer them all in person. If you +mail us a compliment and don't receive a reply, \e{please} don't +think we've ignored you. We did receive it and we were happy about +it; we just didn't have time to tell you so personally. + +To everyone who's ever sent us praise and compliments, in the past +and the future: \e{you're welcome}! + +\H{feedback-address} E-mail address + +The actual address to mail is +\cw{<\W{mailto:putty@projects.tartarus.org}{putty@projects.tartarus.org}>}. diff --git a/doc/licence.but b/doc/licence.but new file mode 100644 index 00000000..28994f67 --- /dev/null +++ b/doc/licence.but @@ -0,0 +1,27 @@ +\versionid $Id: licence.but,v 1.1 2001/12/16 14:56:02 simon Exp $ + +\A{licence} PuTTY Licence + +PuTTY is copyright 1997-2001 Simon Tatham. + +Portions copyright Robert de Bath, Joris van Rantwijk, Delian +Delchev, Andreas Schultz, Jeroen Massar, Wez Furlong, Nicolas Barry. + +Permission is hereby granted, free of charge, to any person +obtaining a copy of this software and associated documentation files +(the "Software"), to deal in the Software without restriction, +including without limitation the rights to use, copy, modify, merge, +publish, distribute, sublicense, and/or sell copies of the Software, +and to permit persons to whom the Software is furnished to do so, +subject to the following conditions: + +The above copyright notice and this permission notice shall be +included in all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND +NONINFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE +FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF +CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION +WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -- 2.11.0