Difference between revisions of "Quality assurance"

From GNUstepWiki
Jump to navigation Jump to search
 
Line 1: Line 1:
 
== Introduction ==
 
== 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.
 
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.
 +
 
 +
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 of system dependent problems as soon as possible.
 
See http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F
 
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.

Latest revision as of 07:59, 29 October 2006

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 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.

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.

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 of system dependent problems as soon as possible. See http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F

We paeticularly need someone with a windows machine to volunteer to take part in this scheme.