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

[Richard Frith-Macdonald]

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
> > GNUstepBase/GSRunLoopWatcher.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.