Menu
▾
▴
Re: [TCLCORE] Patch 2962373 awaiting review: tzdata2010c
|
From: Kevin K. <kev...@gm...> - 2010-03-04 16:34:44
|
Larry McVoy wrote: > Yes, we can, but I'll need a little education on your process. 2952904 > is checked in or it is a patch somewhere? I just need to know how to > do what you want. 2952904 is the bug ID at SourceForge, accessible like any other tracker item. The patch is attached to the bug. The test is simply to launch a Tcl shell and determine that it doesn't write to syslog. (For most patches, the test is to run the test suite; we're generally quite good about including regression test cases with our patches where needed. If you see a patch without a test case it's usually because the existing test suite exposed the bug. The test suite doesn't take that long to run; most of us routinely run the whole thing on one or two configurations before committing.) In this particular case, on the kernel in question, running the full-up test suite *will* write to syslog, because the test suite is intentionally exercising the floating-point software assist. The patch is specifically a change to avoid the annoying message from a Tcl shell that doesn't use the functionality. > Also, I'm stewing on an idea here. Suppose we had CVS installed on > the entire cluster (which I think we do and if not we can). Suppose > we built a simple batch system where you could specify a tuple > > <head revision>, <patch>, <test> > > and we went, checked out that revision, applied the patch, built, and > ran the test and reported back the results. > > Leaving aside the security details of a test like > > /bin/rm -rf / > > or > > cd where/we/keep/bk/src && tar cf - . | mail git+bzr+hg_guys > > would a service like that make any sense? Possibly. It's an idea like the old "SourceForge compile farm;" we'd perhaps do well, before doing anything like that, to try to determine what issues killed it, so that our ship doesn't founder on the same rock. -- 73 de ke9tv/2, Kevin |
