Quality assurance - Revision history

Rfm: /* Introduction */

2006-10-29T07:59:40Z

Introduction

Rfm: /* Compilability test */

2006-10-29T07:56:57Z

Compilability test

Rfm: /* Introduction */

2006-10-29T07:45:22Z

Introduction

Stefan Urbanek at 18:00, 24 February 2005

2005-02-24T18:00:28Z

Stefan Urbanek at 17:59, 24 February 2005

2005-02-24T17:59:59Z

Stefan Urbanek: /* Compilability test */

2005-02-24T08:16:49Z

Compilability test

Stefan Urbanek: /* Compilability test */

2005-02-24T08:01:46Z

Compilability test

Stefan Urbanek at 07:59, 24 February 2005

2005-02-24T07:59:48Z

New page

== Introduction ==

Sometimes the GNUstep does not work as expected or can not be built at all. If the actual code which gets committed (which IMHO is really a basline requirement) was tested then this should not happen. Things which break the entire build cycle should be taken more seriously.

[[User:Aperez|Aperez]]: '' I'd also like to set this up for win32, since that seems to be the thing that breaks fairly often as other patches go into -core. ''

== Compilability test ==

As it is frustrating to check out CVS and have it fail to build for such a trivial reason.

Some sort of automated QA mechanism is necessary, where, upon a new CVS check-in to -base, for example, it is be checked out by an automated QA system and compiled on Linux/x86 as a baseline test. The results of the compilation would be placed on a
webpage. If compilation breakage to any part of -core happened, a
message would be sent to -dev notifying the core team that this had
happpened, the offending file, and the version of the file in CVS at
which the breakage occurred.

Example of a test script:

cd test_directory
rm -rf core GNUstep-test-root
cvs co core
cd core
./build-all GNUstep-test-root &> test-log.txt

''Please refine the code''

@@ Line 1: / Line 1: @@
 == Introduction ==
-Sometimes the GNUstep does not work as expected or can not be built at all. If the actual code which gets committed (which IMHO is really a basline requirement) was tested then this should not happen. Unfortunately there is no waay to guarantee this as it's always possible to make errors in comitting.  However, there are two things which can help with this.
+Sometimes the GNUstep does not work as expected or can not be built at all. If the actual code which gets committed (which IMHO is really a basline requirement) was tested then this should not happen. Unfortunately there is no way to guarantee this as it's always possible to make errors in comitting.  However, there are things which can help with this.
 As a standard procedure developers should build the code and run the testsuites (http://svn.gna.org/viewcvs/gnustep/tests/testsuite/trunk/) before comitting changes.
-Clean builds are run on a nightly basis and the results are sent to the gnustep developers mailing list.  It is important that people volunteer to have their machines participate in this process so that developers can be made aware os system dependent problems as soon as possible.
+It is also good to check out and build code immediately after you have comitted it ... as a sanity check to ensure that you comitted the correct version.
 See http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F
-[[User:Aperez|Aperez]]: '' I'd also like to set this up for win32, since that seems to be the thing that breaks fairly often as other patches go into -core. ''
+We paeticularly need someone with a windows machine to volunteer to take part in this scheme.

← Older revision		Revision as of 07:56, 29 October 2006
Line 9:		Line 9:

	[[User:Aperez\|Aperez]]: '' I'd also like to set this up for win32, since that seems to be the thing that breaks fairly often as other patches go into -core. ''		[[User:Aperez\|Aperez]]: '' I'd also like to set this up for win32, since that seems to be the thing that breaks fairly often as other patches go into -core. ''
−
−	~~== Compilability test ==~~
−
−	~~As it is frustrating to check out CVS and have it fail to build for such a trivial reason.~~
−
−	Some sort of automated QA mechanism is necessary, where, upon a new CVS check-in to -base, for example, it is be checked out by an automated QA system and compiled on Linux/x86 as a baseline test. The results of the compilation would be placed on a
−	~~webpage. If compilation breakage to any part of -core happened, a~~
−	~~message would be sent to -dev notifying the core team that this had~~
−	~~happpened, the offending file, and the version of the file in CVS at~~
−	~~which the breakage occurred.~~
−
−	~~Idea of a primitive test script for compilability:~~
−
−	~~cd test_directory~~
−	~~rm -rf core GNUstep-test-root~~
−	~~cvs co core~~
−	~~cd core~~
−	~~./build-all $test_directory/GNUstep-test-root &> test-log.txt~~
−
−	~~[[Category:Project procedures]]~~

← Older revision		Revision as of 18:00, 24 February 2005
Line 23:		Line 23:
	./build-all $test_directory/GNUstep-test-root &> test-log.txt		./build-all $test_directory/GNUstep-test-root &> test-log.txt

−	[[Category:~~Procedures~~]]	+	[[Category:Project procedures]]

← Older revision		Revision as of 17:59, 24 February 2005
Line 22:		Line 22:
	cd core		cd core
	./build-all $test_directory/GNUstep-test-root &> test-log.txt		./build-all $test_directory/GNUstep-test-root &> test-log.txt
		+
		+	[[Category:Procedures]]

@@ Line 15: / Line 15: @@
 which the breakage occurred.
-Idea of a test script:
+Idea of a primitive test script for compilability:
   cd test_directory

@@ Line 15: / Line 15: @@
 which the breakage occurred.
-Example of a test script:
+Idea of a test script:
   cd test_directory
@@ Line 21: / Line 21: @@
   cvs co core
   cd core
-  ./build-all GNUstep-test-root &> test-log.txt
+  ./build-all $test_directory/GNUstep-test-root &> test-log.txt