Report Bugs - Revision history

Multix: new issue trackers, savannah is legacy

2022-01-13T14:32:35Z

new issue trackers, savannah is legacy

Rfm at 08:18, 4 March 2013

2013-03-04T08:18:30Z

Rfm: /* What to Report */

2013-02-28T07:21:03Z

What to Report

Rfm at 07:16, 28 February 2013

2013-02-28T07:16:35Z

Rfm: /* Sending Fixes */

2011-10-02T13:33:21Z

Sending Fixes

Rfm: /* What to Report */

2011-10-02T13:29:21Z

What to Report

Madleser: ported from website

2006-09-02T10:58:17Z

ported from website

New page

Please report bugs via the [https://savannah.gnu.org/bugs/?group=gnustep GNUstep Bug Tracking database]. You can then query the database any time to see the status of your bug report. Due to spam being sent through bug reports, you now have to be a registered user before submitting a bug. Alternatively, you may report bugs by sending a message to [http://mail.gnu.org/mailman/listinfo/bug-gnustep bug-gnustep@gnu.org].

User testing is vital for improving GNUstep, so please report any bugs you find!

== What to Report ==

Please include as much of this information as possible when submitting your report:
* GNUstep version and snapshot date or date of last update from CVS (ideally, on finding a bug you should update your system to the latest version in the CVS repository, in order to avoid reporting problems that have already been fixed).
* Machine/Operating system on which you are running
* Compiler version you use
* A description of the problem, along with either a test program to demonstrate the problem, or a description of how to make the problem appear in one of the test programs that come as part of the GNUstep distribution.
** If you have a problem configuring the libraries, please send the config.log file
** If you have a problem compiling a library or application, please send the complete output of make or at least enough to show what went wrong. If you are using sh or bash, do this: <tt>make messages=yes > output.txt 2>&1</tt>

The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is.

== Sending Fixes ==

Actually fixing problems is even more appreciated than sending in bug reports. To do this, first fix the bug and make sure it works. Then send in a diff file containing the differences between the old version of the file(s) you changed and the new version. Use the diff (<tt>diff -u oldfile newfile > file.patch</tt>) program to do this. Then add a ChangeLog entry in front of this and send the whole thing to the bug database.

If you use emacs, it is easy to add a ChangeLog entry. Just edit the file you changed, and move the cursor to the function or method you changed, then type <tt>M-x add-change-log-entry</tt> and emacs automatically formats an entry in the ChangeLog file with the information on the file and function you changed. You just need to add a comment about what was fixed. Note: Don't send a diff of the ChangeLog file, just send a copy of your ChangeLog entry normally. Here is an example ChangeLog:

<pre>
* src/NSAutoreleasePool.m ([NSAutoreleasePool -addObject:]):
Remove double_release checking. Increment released_count after
setting released array.
([NSAutoreleasePool -dealloc]): Catch release errors.
([NSAutoreleasePool -enableDoubleReleaseCheck:]): Removed method.

* src/NSObject.h ([NSObject -autorelease], [NSObject -release]):
Add double_release checking.
([NSObject +enableDoubleReleaseCheck:]): New method.

* src/Foundation/NSAutoreleasePool.h: Remove
+enableDoubleReleaseCheck:, add +autoreleaseCountForObject:.

* src/Foundation/NSObject.h: Add +enableDoubleReleaseCheck:.

* src/Foundation/objc-load.h: Include objc-api file.
</pre>

← Older revision		Revision as of 08:18, 4 March 2013
Line 44:		Line 44:
	* src/Foundation/objc-load.h: Include objc-api file.		* src/Foundation/objc-load.h: Include objc-api file.
	</pre>		</pre>
		+
		+	== One thing at a time ==
		+
		+	Please try to ensure that, you only address one issue at a time (ie try to ensure that different issues are kept clearly separate, not bundled together) and address complex issues in stages, completing one stage before going on to the next.
		+	This keeps things managable, and allows other people to understand/address the issues efficiently and quickly.

@@ Line 13: / Line 13: @@
 ** If you have a problem compiling a library or application, please send the complete output of make or at least enough to show what went wrong. If you are using sh or bash, do this: <tt>make messages=yes > output.txt 2>&1</tt>
-The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is.
+The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is.  If possible, the test program should be in the form of a testcase (to be built/run using the gnustep-tests script) for inclusion into the testsuites - such testcases can readily be run on MacOSX as a reference platform so that we can tell what the correct behavior is.
 If your problem is that some API from OSX 10.5 or later is unimplemented, please report it as a 'Change Request' rather than a 'Bug', and (ideally) contribute an implementation of the missing functionality.  In this case please provide documentation for the missing API and a test case to demonstrate what it does.

@@ Line 21: / Line 21: @@
 Actually fixing problems is even more appreciated than sending in bug reports. To do this, first fix the bug and make sure it works. Then send in a diff file containing the differences between the old version of the file(s) you changed and the new version. Use the diff (<tt>diff -u oldfile newfile > file.patch</tt>) program to do this.
 For new APIs, provide header changes as well as source code changes, with macros bracketing the changes to specify which version of OSX they correspond to (see existing headers or examples) and comments in the headers documenting the behaviors of new methods etc.
-For both bugfixes and new functionality, please provide testcases (see the existing testsuite for examples) which demonstrate the correct behavior of the code.
+For both bugfixes and new functionality, please, please, PLEASE provide testcases (see the existing testsuite for examples) which demonstrate the correct behavior of the code.  Without testcases it's much harder to review patches, so if you don't provide testcases, your patch may simply be ignored.  Testcases are executed using the gnustep-tests script from the gnustep-make package.
-Then add a ChangeLog entry in front of this and send the whole thing to the bug database.
+Add a ChangeLog entry in front of the diff file, and send the whole thing (patch plus testcases) to the bug database.
 If you use emacs, it is easy to add a ChangeLog entry. Just edit the file you changed, and move the cursor to the function or method you changed, then type <tt>M-x add-change-log-entry</tt> and emacs automatically formats an entry in the ChangeLog file with the information on the file and function you changed. You just need to add a comment about what was fixed. Note: Don't send a diff of the ChangeLog file, just send a copy of your ChangeLog entry normally. Here is an example ChangeLog:

← Older revision		Revision as of 13:29, 2 October 2011
Line 14:		Line 14:

	The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is.		The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is.
		+
		+	If your problem is that some API from OSX 10.5 or later is unimplemented, please report it as a 'Change Request' rather than a 'Bug', and (ideally) contribute an implementation of the missing functionality. In this case please provide documentation for the missing API and a test case to demonstrate what it does.

	== Sending Fixes ==		== Sending Fixes ==

@@ Line 1: / Line 1: @@
-Please report bugs via the [https://savannah.gnu.org/bugs/?group=gnustep GNUstep Bug Tracking database]. You can then query the database any time to see the status of your bug report. Due to spam being sent through bug reports, you now have to be a registered user before submitting a bug. Alternatively, you may report bugs by sending a message to [http://mail.gnu.org/mailman/listinfo/bug-gnustep bug-gnustep@gnu.org].
+The original savannah bug tracker [https://savannah.gnu.org/bugs/?group=gnustep GNUstep Bug Tracking database] is considered legacy, it is there only as reference and to gradually close bugs, but please do not add new ones.
 User testing is vital for improving GNUstep, so please report any bugs you find!
@@ Line 6: / Line 27: @@
 Please include as much of this information as possible when submitting your report:
-* GNUstep version and snapshot date or date of last update from CVS (ideally, on finding a bug you should update your system to the latest version in the CVS repository, in order to avoid reporting problems that have already been fixed).
+* GNUstep version and snapshot date or date of last update from GIT (ideally, on finding a bug you should update your system to the latest version in the GIT repository, in order to avoid reporting problems that have already been fixed).
 * Machine/Operating system on which you are running
-* Compiler version you use
+* Compiler version and Runtime you use (GCC, CLang)
 * A description of the problem, along with either a test program to demonstrate the problem, or a description of how to make the problem appear in one of the test programs that come as part of the GNUstep distribution.
 ** If you have a problem configuring the libraries, please send the config.log file
 ** If you have a problem compiling a library or application, please send the complete output of make or at least enough to show what went wrong. If you are using sh or bash, do this: <tt>make messages=yes > output.txt 2>&1</tt>
-The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is.  If possible, the test program should be in the form of a testcase (to be built/run using the gnustep-tests script) for inclusion into the testsuites - such testcases can readily be run on MacOSX as a reference platform so that we can tell what the correct behavior is.
+The provision of a test/demonstration program is very important for getting the bug fixed quickly. Often, with no test program, we will not do anything with the report for a long time unless it is immediately obvious what the problem is.  If possible, the test program should be in the form of a testcase (to be built/run using the gnustep-tests script) for inclusion into the testsuites - such testcases can readily be run on MacOS as a reference platform so that we can tell what the correct behavior is.
-If your problem is that some API from OSX 10.5 or later is unimplemented, please report it as a 'Change Request' rather than a 'Bug', and (ideally) contribute an implementation of the missing functionality.  In this case please provide documentation for the missing API and a test case to demonstrate what it does.
+If your problem is that some API from OSX 10.5 or later is unimplemented, please label it as a 'Feature Request' rather than a 'Bug', and (ideally) contribute an implementation of the missing functionality.  In this case please provide documentation for the missing API and a test case to demonstrate what it does.
 == Sending Fixes ==