[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] gnustep/core/base ChangeLog Headers/Additions/G...

From: Richard Frith-Macdonald
Subject: Re: [Gnustep-cvs] gnustep/core/base ChangeLog Headers/Additions/G...
Date: Thu, 24 Feb 2005 08:27:04 +0000

On 23 Feb 2005, at 20:55, Alex Perez wrote:

Fred Kiefer wrote:
Hi Richard,
Richard Frith-Macdonald wrote:
CVSROOT:    /cvsroot/gnustep
Module name:    gnustep
Branch: Changes by: Richard Frith-Macdonald <address@hidden> 05/02/23 16:05:09

Modified files:
core/base : ChangeLog core/base/Headers/Additions/GNUstepBase: GSFileHandle.h core/base/Headers/Foundation: NSPort.h NSRunLoop.h core/base/Source: GNUmakefile GSFileHandle.m GSLocale.m NSPipe.m NSRunLoop.m NSSocketPort.m NSThread.m NSUser.m core/base/Source/Additions: GSXML.m core/base/Testing: nsconnection.m nsfilehandle.m Added files: core/base/Source/unix: GNUmakefile GSRunLoopCtxt.m GSRunLoopWatcher.m Makefile.preamble core/base/Source/win32: GNUmakefile GSRunLoopCtxt.m GSRunLoopWatcher.m Makefile.preamble NSRunLoopWin32.m
Log message:
    Apply modified patch to support windows native event handling

Looks like you did miss out on a few header files when applying this patch. When compiling base I get the following files listed as missing: GNUstepBase/GSRunLoopCtxt.h

Two for Two. This is a touchy subject, but it just keeps happening over and over and over again. Richard, would it be possible for you to actually /test/ the code you commit to CVS? (not the code you write on your machine, the actual code which actually gets comitted to CVS, the code other people must use)? The entire GNUstep community will benefit from higher QC, Lets learn from our mistakes, instead of repeating them bi-weekly.

A few points -
1. While any error is regratable, I already tested the CVS checkout and fixed the missing files yesterday. 2. A few hours delay in the process is because I have a life ... and pausing to deal with more immediate issues like children and to go to my aikido class is a priority. 3. CVS is for this ... so that it's easy to get files from an earlier version etc.

As for 'would it be possible for you to actually /test/ the code you commit to CVS' ... I don't think it's reasonably possible to test whether I've committed all the correct files before committing.

In this case, I committed the files then checked out the library onto another machine and built a clean system to test that they were all ok.

If you look at the savannah comments on the patch, you will see a summary of what functionality was tested before the commit.

Generally, I build and run the testsuite on my Debian system before any commit.

Often I also build and run a few tests (I don't have the guile test suite installed) on Solaris.

In this case (as I've installed a working windoze-xp system in the last week, and because this was primarily a mingw32 patch) the testing was done under xp too (though like solaris I don't have the testsuite installed, so only used the test programs in the base/Testing area).

Usually small windows patches get no testing under windows, but are tested under Debian to ensure that they don't break the unix code ... simply because I don't normally have a windows system, and rely on the few people who do to notify me of any problems. I'm not really happy with that ... but given my time constraints, I have to rely on other people to do a lot of the testing for me. The situation is similar (or worse) for BSD, as I don't have
a BSD system at all.

Total time taken applying/debugging/testing this patch ... about 16 hours (excluding installing xp and getting everything for base downloaded and working on xp). Final testing, about 30 minutes.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]