codestriker-user Mailing List for Codestriker: collaborative code reviewer (Page 38)
Brought to you by:
sits
Menu
▾
▴
codestriker-user — Discussion of any issue to do with Codestriker
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(12) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
(1) |
Apr
(6) |
May
(3) |
Jun
(1) |
Jul
|
Aug
(9) |
Sep
(2) |
Oct
(2) |
Nov
(8) |
Dec
(6) |
| 2004 |
Jan
(12) |
Feb
(19) |
Mar
(2) |
Apr
(2) |
May
(4) |
Jun
(11) |
Jul
|
Aug
(14) |
Sep
(4) |
Oct
(27) |
Nov
(4) |
Dec
(22) |
| 2005 |
Jan
(14) |
Feb
(2) |
Mar
(11) |
Apr
(3) |
May
(14) |
Jun
(60) |
Jul
(58) |
Aug
(76) |
Sep
(72) |
Oct
(59) |
Nov
|
Dec
(4) |
| 2006 |
Jan
(1) |
Feb
(5) |
Mar
(13) |
Apr
(11) |
May
(30) |
Jun
(17) |
Jul
(18) |
Aug
(39) |
Sep
|
Oct
|
Nov
|
Dec
(17) |
| 2007 |
Jan
(18) |
Feb
(5) |
Mar
(20) |
Apr
(2) |
May
(3) |
Jun
(13) |
Jul
(11) |
Aug
(4) |
Sep
(6) |
Oct
(9) |
Nov
(3) |
Dec
|
| 2008 |
Jan
(10) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(9) |
Jul
(10) |
Aug
(10) |
Sep
(13) |
Oct
(34) |
Nov
(12) |
Dec
(8) |
| 2009 |
Jan
(4) |
Feb
(11) |
Mar
(12) |
Apr
(3) |
May
(36) |
Jun
(4) |
Jul
(11) |
Aug
(12) |
Sep
(25) |
Oct
(13) |
Nov
(9) |
Dec
|
| 2010 |
Jan
|
Feb
(12) |
Mar
(6) |
Apr
(10) |
May
(12) |
Jun
|
Jul
(4) |
Aug
(9) |
Sep
(12) |
Oct
(3) |
Nov
(6) |
Dec
(3) |
| 2011 |
Jan
(2) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
(3) |
Jun
(8) |
Jul
|
Aug
(14) |
Sep
|
Oct
(3) |
Nov
(1) |
Dec
|
| 2012 |
Jan
(2) |
Feb
(10) |
Mar
(4) |
Apr
(3) |
May
(2) |
Jun
(5) |
Jul
|
Aug
(3) |
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(2) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: David S. <si...@us...> - 2004-06-08 00:17:07
|
Hi Paul, The current version of Codestriker won't let you do this. Its pretty easy to fix this though - I'll send a patch to you to try out, and make sure it is included in the upcoming 1.8.2 release. Cheers, David On Mon, 7 Jun 2004 19:23, Paul Huang wrote: > Hi All > > I am now behind a firewall, in order to access cvs repo across the > firewall, I need to set the proxy accordingly. > > In WinCVS, I see the following configuration information when I login to > the cvsrepo. > > :pserver;proxy=abc.com;proxyport=8080:pau...@cv... > > I tried to copy the same info into codestriker configuration file. > However, it does not work. > > Does any one know how to configure Codestriker in this case? > > Thanks a lot. -- Cheers, David |
|
From: Paul H. <pau...@su...> - 2004-06-07 09:33:54
|
Hi All I am now behind a firewall, in order to access cvs repo across the firewall, I need to set the proxy accordingly. In WinCVS, I see the following configuration information when I login to the cvsrepo. :pserver;proxy=abc.com;proxyport=8080:pau...@cv... I tried to copy the same info into codestriker configuration file. However, it does not work. Does any one know how to configure Codestriker in this case? Thanks a lot. -- Best Regards Paul Huang Software Engineer ============================================== Desktop/CDE&Java Group Sun Microsystem China Engineering & Research Institute 10/F Chuangxin Plaza, Tsinghua Science Park Beijing 100084, P.R.China (Tel): +86-10-8261-8200 ext. 82872 (Fax): +86-10-6278-0969 |
|
From: Your S. <you...@ti...> - 2004-05-29 18:43:18
|
Important Message to MY Downline, I just received an urgent warning email from the accounts department of the online business that you joined a few months back. They told me that you have not yet confirmed acceptance of your last months stats or money earned. If you don't do this immediately then not only will you miss being paid out, it will also mean I don't get paid my over rides which will be very sad as I am owed $12,152USD this month. Please, simply visit this link and log into your account and accept your stats statement and collect your earnings so I can get mine too. Please, click here: http://ftbb.captureform.biz/capture/ftbb/affiliates.htm Many Thanks In Advance Ken Please note: ------------------------------------------------------------------------ This is an automatic email delivered to my downline via e-soft ware. If you feel that I've breached your privacy or you would simply prefer not to receive any further reminders, please click this link or copy this URL into your browser>> http://ftbb.captureform.biz/capture/ftbb/removeme.htm and you will be immediately and automatically unsubscribed from my downline list. If this email has been received in error please accept my apologies. |
|
From: Melisa H. <OTA...@bi...> - 2004-05-23 12:40:14
|
<html><head><title>bronchiole belch erickson grainy distillery millard myr= iad ago copernicus lick racy tribal alone practical allegro susan peritect= ic cornwall geiger shannon hermetic patrol prison junta bedrock combinate = emit donahue impede=20</title><meta http-equiv=3DContent-Type content=3D"t= ext/html; charset=3Diso-8859-1"></head><body bgcolor=3D#FFFFFF text=3D#000= 000><font color=3D#fffdff>robe schlitz priscilla write couple carolingian = peafowl aide workshop glitch math brimful granville transcendental chandel= ier physiotherapist tawdry uppercut rebellion vow scarf=20</font><br> <fon= t color=3D#eff1f5>oklahoma conquest emily cutoff lake contagious lamb apat= hy borealis hibernia ukraine scarborough seismology duffel areawide garth=20= </font><br> <font color=3D#faf5f6>cloudy grille kombu adventitious erotic = mate doltish bayport block chao banbury mythic doorstep nineveh bentley pr= ecaution transferable=20</font><br> <font color=3D#fdfdfe>polyhymnia offer= lapidary reredos bluebush delaware illinois ectoderm wraith bunsen goldst= ein puffball riggs addressograph stanchion snipe dec carp anticipate phony= summers concurred=20</font><br> <font color=3D#f7e1ff>vacuole clannish bu= tt danielson door ellipsis creepy journey andorra paraphernalia clean soil= decomposition disburse brindisi scaup bolivar agent hymn helen decrypt sp= oradic circumvent=20</font><br> <font color=3D#fdeded>conner pogo buried c= ompelled local laconic cotman screwdriver chairmen deprecatory orangutan a= ppalachia emblem jungle concerto=20</font><br> <font color=3D#eaf1e4>fir c= ounterfeit boy antarctica attendee amsterdam rob swami deny ridge babe zea= lous macho disposable zinc conundrum abuilding deallocate estimable arrest= advise penurious laura donor=20</font><br> <b><a hrefppmhref=3Dhttp://con= struct.com href=3Dhttp://einsteinian.favouritepc.com/index.php?s=3D4241&t=3D= stiletto><font size=3D5>Take 95% discounts on Win 2000, XP, Office, Adobe,= Corel products from Blount's SoftShop</font></a></b><br> <font color=3D#f= ffdff>locust sensual beneficial vanadium enormity destitute hutchinson cro= ckett drophead sandalwood vanadium cutler deuce conservative cholinesteras= e siegel bayonne destruct literature=20</font><br> <font color=3D#f2f8ed>c= oarsen constraint areawide honoraria were valet carburetor omaha away berr= a pervade befitting connubial chronography piscataway abusive harold angio= sperm dreary elves coerce elevate faraday deborah realty defocus george el= ectroencephalogram augustine inlet=20</font><br> <font color=3D#e7fbe5>con= centric convince mensurable arctan commotion coachwork cogitate knudsen me= rmaid bruce sonic qualified implicant mountaineer thorpe artistry desorpti= on deerstalker dividend salvador trilobite passband asperity compelling du= ct greenish anteroom tone abreast miracle dale dried purl columbus kenyon = equinoctial electret clyde sibley elsewhere=20</font><br> <font color=3D#e= 4e7e7>retrogressive vestry transoceanic evildoer nostalgic dub storey gnei= ss caribbean masterful alumnae gradual w's=20</font><br> <font color=3D#f2= f8ed>clove bucknell marlin cincinnati christoph thymus snapshot classroom = debilitate brow workplace microcosm certified bungalow econometric lindsey= solid liverwort crater nearby argentina virgule pickerel apprehensive sto= rey retentive falconry rhombohedral hydrolysis marino=20</font><br> <font = color=3D#f4e1f0>drawbridge broke turk cacm doodle token aide disc emblem d= iopter judson kochab bicker whine maintain edmonds dram wholehearted toler= ant dictate jerry chromatograph hypochlorous macbeth countrify suppose gis= t nne=20</font><br> <font color=3D#eee6eb>ammeter gosling rabbet fabric cr= ossbow paz calla attic caste handicapped karachi cancelled pagoda admire a= postrophe electrocardiograph coffeepot northrop magog vow groundwork maloc= clusion exhortation anne dovekie ellis dunkirk irretrievable waitress=20</= font></body></html> |
|
From: John <Loo...@ey...> - 2004-05-15 18:54:12
|
E-mail is the fastest growing marketing tool. We offer E-mail Marketing with quality service and the lowest prices. 1. Targeted E-mail Addresses We can provide targeted e-mail addresses you need, which are compiled only on your order. We will customize your customer e-mail addresses. * We have millions of e-mail addresses in a wide variety of categories. 2. Send out Targeted E-mails for you We can send your e-mail message to your targeted customers! We will customize your email addresses and send your message for you. * We can Bullet Proof your Web Site $ dedicated server. We also offer Fax Broadcasting Service. For more details, you can refer to: Http://www.9206.com Looking forward to serving you. Regards! John Okoh www.9206.com Su...@92... ************************************************************************* To take your address: Http://213.172.0x1f.16/index.html ************************************************************************* |
|
From: David S. <si...@us...> - 2004-04-29 11:29:08
|
Hi Guys, Codestriker 1.8.1 is now available. Below are the relevant entries from the CHANGELOG file. Cheers, The Codestriker Team. http://codestriker.sf.net * Added some missing imports which caused compilation errors for Perl 5.8.3 on Solaris when checksetup.pl was run. * Made checksetup.pl more graceful when DBI.pm is not installed, and it is checking what other database modules are required. * Fixed bug found by Philipp Frauenfelder where LXR integration was not working when the LXR database was password protected. The following changes were from Jason Remillard: * Fixed bug in the metric support has been fixed, which prevented the metric data from being usable if more than one reviewer was present. * Fixed bug where the wrong Codestriker time number was reported in the metric summary page. * Emails sent from topic property changes now include more information such as what specific properties were changes. Topic creation emails also include the list of files which have been changed. |
|
From: David S. <si...@us...> - 2004-04-01 02:54:53
|
Guys, At long last - Codestriker 1.8 has been released. I've attached the summary of changes and the CHANGELOG entries for this release, which has been a long time coming. We are hoping to do more frequent releases from this point onwards. Grab it from http://codestriker.sf.net. Enjoy - The Codestriker Team. From the NEWS: This major release introduces the capability for automatically and manually recording configurable software metrics against your code reviews. It is also possible to generate reports based on these metrics to access the effectiveness of your code reviews. In addition to MySQL and PostgreSQL, Codestriker now supports Oracle and SQL-Server via ODBC. There is also the introduction of Perforce depot integration. Topic properties can now been modified after a topic has been created. Wildcard searching is now supported on the search screen for author, reviewer and cc fields. An audit trail for a topic is now recorded, so that it is possible to see when a topic was created, who has modified it and when that occurred. Codestriker now supports execution under IIS, for Win32 deployments, although Apache can of course be used too. From the CHANGELOG: * Initial support for Perforce integration. Can handle topic text from a Perforce describe command, such as: "p4 describe -du <changenumber>" or "p4 diff -du". * Codestriker now works under IIS as well as Apache. Use IPC::Open3 rather than IPC::Run (which doesn't work under IIS) within the CvsLocal and CvsPserver modules when fetching remote diff data from CVS. IPC::Run is no longer used. * A new configuration variable $tmpdir is in codestriker.conf for unusual setups which can't use the system default temporary directory for the creation of temporary files. Win32 systems are the usual culprit. * The CVS rdiff parser didn't correctly handle new files within the diff on Win32 platforms. * Add more win32 example configuration to codestriker.conf. * Include the relevant DBD modules in the checksetup.pl dependency list, depending on what database system has been configured. * Some minor fixes to fully support Win32-based CVS repositories, including use of the older-style :local:c:\\cvsrep syntax. Also be more robust in handling directory separators as either forward or backward slashes, since different versions of CVSNT support this. Make sure the CVS executable path is quoted, since it will often contain spaces for Win32 environments. * Improved useability of messages (when Perl modules are missing) for Win32 users. * Now support ODBC and Oracle databases. The Database creation/upgrade code has been modified so that it is properly modularised, and so checksetup.pl is far more maintainable. Adding support for new Databases will now be a snap. The file table had to be renamed to topicfile, and comment to commentdata to avoid reserved word clashes in ODBC and Oracle. * Added in a new topic listener which records all changes to a comment's state, property changes to a topic and when a topic has been viewed. Three new database tables have been added to store this information, which can be accessed from the metrics tab of a topic. * Added in the ability for the topic's properties to be changed, including the title, author, bug ids, reviewers, cc, repository, project, description and state. Updated the topic listeners to now take the old and new topic objects as arguments. * Introduction of per-user and per-topic metrics functionality from Jason Remillard. In the process, the UI has been changed, plus some general refactoring. It is possible to generate reports based on these metrics over a collection of topics and time, to give some indications on the effectiveness of code reviewing. * The $Codestriker::allow_repository configuration variable is removed since this boolean value can be derived from the length of the @valid_repositories list. From Jason Remillard. * Use tempfile() in Parser.pm to close a potential security hole, from Jason Remillard. * The topic search screen has been reworked to contain "What's this?" links to make the individual search fields clearer. Also, allowed the use of wildcards with the Author, Reviewer and Cc search fields. -- Cheers, David |
|
From: David S. <si...@us...> - 2004-03-26 01:13:20
|
Hi Eric, I take it you have run the checksetup.pl script in bin? If you do, this will ensure that the appropriate "use lib" declaration is present in the generated cgi-bin/codestriker.pl file (make sure it looks right). Make sure Apache is restarted after you run checksetup.pl, so that the first time Codestriker is loaded, mod_perl has the right libraries loaded. Cheers, David On Fri, 26 Mar 2004 09:14, eric cocozza wrote: > Hi, > > I just installed codestriker, but am getting the error bellow in my > apache error_log. The file it is looking for is in > /home/httpd/vhosts/mindscraps.com/httpdocs/codestriker/lib but I can't > figure out how to add this to @INC. Or perhaps I should just move the > lib into one of the already included directory? Any help is appreciated. > please CC me as I'm not subscribed to the list. > > Thanks! > > -Eric > > [Thu Mar 25 16:29:52 2004] [error] 17795: ModPerl::Registry: Can't > locate Codestriker.pm in @INC (@INC contains: ../lib > /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 > /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi > /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl > /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi > /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at > /home/httpd/vhosts/mindscraps.com/httpdocs/codestriker/cgi-bin/codestrik >er.pl line 37.!BEGIN failed--compilation aborted at > /home/httpd/vhosts/mindscraps.com/httpdocs/codestriker/cgi-bin/codestrik >er.pl line 37.! -- Cheers, David |
|
From: eric c. <eco...@ho...> - 2004-03-25 22:14:36
|
Hi, I just installed codestriker, but am getting the error bellow in my = apache error_log. The file it is looking for is in = /home/httpd/vhosts/mindscraps.com/httpdocs/codestriker/lib but I can't = figure out how to add this to @INC. Or perhaps I should just move the = lib into one of the already included directory? Any help is appreciated. = please CC me as I'm not subscribed to the list. Thanks! -Eric [Thu Mar 25 16:29:52 2004] [error] 17795: ModPerl::Registry: Can't = locate Codestriker.pm in @INC (@INC contains: ../lib = /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 = /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi = /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl = /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi = /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at = /home/httpd/vhosts/mindscraps.com/httpdocs/codestriker/cgi-bin/codestrike= r.pl line 37.!BEGIN failed--compilation aborted at = /home/httpd/vhosts/mindscraps.com/httpdocs/codestriker/cgi-bin/codestrike= r.pl line 37.! |
|
From: Jason R. <jre...@ya...> - 2004-02-25 02:07:53
|
Hi, If you are having trouble compiling the IPC module for redhat, you should attempt to find a precompiled RPM to install. When I googled for IPC perl and RPM, I found the following page that has the IPC modules already compiled for redhat. I don't run redhat, so I have not used the site, but it looks pretty complete. http://rpmpan.sourceforge.net/IPC.html It seems to have a ton of perl modules compiled into RPM's. Also, since you are using the supported version of redhat, you may be able to get the RPM directly from the redhat network. I can't seem to find a way of searching the modules that they have, but since you are paying for it you should check that out. If redhat has the modules, you should try them first. If you don't get anywhere with the RPM's, then you should send us the output of the complete CPAN session. Thanks Jason. __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |
|
From: David S. <si...@us...> - 2004-02-24 21:54:57
|
Hi Brent, I'd mail the maintainer, who is Barrie Slaymaker <ba...@sl...> with your problem. Tell him what your platform is and Perl version, include your failed tests below and hopefully he can help you. Please keep us posted on how you go, as I can update the documentation if this is a known problem. While you are waiting for a response from him, it still might be worth forcing the install to order to make some progress. Codestriker only uses the simple functions from IPC::Run, so chances are it won't matter. Cheers, David On Wed, 25 Feb 2004 02:30, Barker, Brent wrote: > David, > > Thanks for the rapid response. The version of IPC-Run is 0.77. > Here are a few of the errors from while running > Pseudo-hashes are deprecated at > /root/.cpan/build/IPC-Run-0.77/blib/lib/IPC/Run/ IO.pm line 564. > t/timer............ok 17/72Pseudo-hashes are deprecated at (eval 1) line > 68. Pseudo-hashes are deprecated at (eval 1) line 68. > Failed Test Stat Wstat Total Fail Failed List of Failed > ------------------------------------------------------------------------ >---- --- > t/pump.t 255 65280 27 18 66.67% 10-27 > t/run.t 266 28 10.53% 56 62 75 80 85 90 95 100 105 > 110 115 > 120 125 131 143 148 153 158 > 173 178 > 183 217 228 240 247 254 260 > 266 (1 subtest UNEXPECTEDLY SUCCEEDED), 61 subtests skipped. > Failed 2/15 test scripts, 86.67% okay. 46/703 subtests failed, 93.46% > okay. make: *** [test_dynamic] Error 29 > /usr/bin/make test -- NOT OK > Running make install > make test had returned bad status, won't install without force > > I tried to run IPC::Run maintainer without success as you can seee > below. > > perl -MCPAN -e 'install "IPC::Run maintainer"' > CPAN: Storable loaded ok > Going to read /root/.cpan/Metadata > Database was generated on Fri, 20 Feb 2004 20:49:55 GMT > Warning: Cannot install IPC::Run maintainer, don't know what it is. > Try the command > > i /IPC::Run maintainer/ > > to find objects with matching identifiers. > > > Whe I run i /IPC:Run maintainer/ if fails with; > Can't open perl script "i": No such file or directory > > Regards, > > Brent > -----Original Message----- > From: David Sitsky > To: Barker, Brent > Cc: cod...@li... > Sent: 2/23/04 5:43 PM > Subject: Re: [Codestriker-user] Perl-CPAN problems > > On Tue, 24 Feb 2004 11:35, Barker, Brent wrote: > > I am running RedHat Enterprise Server v3. While running > > ./checksetup.pl > > > data is returned telling me to run: > > > > perl -MCPAN -e 'install "IPC::Run"' > > perl -MCPAN -e 'install "Template"' > > > > When executed; make: *** [test_dynamic] Error 29 is returned. > > > > Make test had returned bad status, won't install without forc > > Hmmm, I take it this message is from the IPC::Run module install? I did > a > quick search on the web, and noticed a similar error message. I'm not > sure how critical this failed test is, I have not had issues with > IPC::Run > in production use. > > http://www.nntp.perl.org/group/perl.cpan.testers/12949 > > What version of IPC::Run is it trying to install? It might be worth > following this up with the IPC::Run maintainer, and even trying a forced > > install. -- Cheers, David |
|
From: Barker, B. <bre...@vi...> - 2004-02-24 15:38:26
|
David,
Thanks for the rapid response. The version of IPC-Run is 0.77.
Here are a few of the errors from while running
Pseudo-hashes are deprecated at
/root/.cpan/build/IPC-Run-0.77/blib/lib/IPC/Run/ IO.pm line 564.
t/timer............ok 17/72Pseudo-hashes are deprecated at (eval 1) line 68.
Pseudo-hashes are deprecated at (eval 1) line 68.
Failed Test Stat Wstat Total Fail Failed List of Failed
----------------------------------------------------------------------------
---
t/pump.t 255 65280 27 18 66.67% 10-27
t/run.t 266 28 10.53% 56 62 75 80 85 90 95 100 105 110
115
120 125 131 143 148 153 158 173
178
183 217 228 240 247 254 260 266
(1 subtest UNEXPECTEDLY SUCCEEDED), 61 subtests skipped.
Failed 2/15 test scripts, 86.67% okay. 46/703 subtests failed, 93.46% okay.
make: *** [test_dynamic] Error 29
/usr/bin/make test -- NOT OK
Running make install
make test had returned bad status, won't install without force
I tried to run IPC::Run maintainer without success as you can seee below.
perl -MCPAN -e 'install "IPC::Run maintainer"'
CPAN: Storable loaded ok
Going to read /root/.cpan/Metadata
Database was generated on Fri, 20 Feb 2004 20:49:55 GMT
Warning: Cannot install IPC::Run maintainer, don't know what it is.
Try the command
i /IPC::Run maintainer/
to find objects with matching identifiers.
Whe I run i /IPC:Run maintainer/ if fails with;
Can't open perl script "i": No such file or directory
Regards,
Brent
-----Original Message-----
From: David Sitsky
To: Barker, Brent
Cc: cod...@li...
Sent: 2/23/04 5:43 PM
Subject: Re: [Codestriker-user] Perl-CPAN problems
On Tue, 24 Feb 2004 11:35, Barker, Brent wrote:
> I am running RedHat Enterprise Server v3. While running
./checksetup.pl
> data is returned telling me to run:
>
> perl -MCPAN -e 'install "IPC::Run"'
> perl -MCPAN -e 'install "Template"'
>
> When executed; make: *** [test_dynamic] Error 29 is returned.
>
> Make test had returned bad status, won't install without forc
Hmmm, I take it this message is from the IPC::Run module install? I did
a
quick search on the web, and noticed a similar error message. I'm not
sure how critical this failed test is, I have not had issues with
IPC::Run
in production use.
http://www.nntp.perl.org/group/perl.cpan.testers/12949
What version of IPC::Run is it trying to install? It might be worth
following this up with the IPC::Run maintainer, and even trying a forced
install.
--
Cheers,
David
|
|
From: Matthew H. <mat...@wa...> - 2004-02-24 15:22:10
|
Brent, Funny enough. I had problems installing IPC::RUN and Template also. I just ran each perl -MCPAN -e 'install...' independently, then ran ./checksetup.pl, then maybe had to do that a few times, then everything installed finally. I know this isn't a pretty way to go about it, but it seemed to work for me. I did this approach on two servers which I installed Codestriker on, and both had the same problem. If you do inquire the IPC::Run or Template maintainer (as David suggested) and find a fix, please share. Good luck! Matthew -----Original Message----- From: Barker, Brent [mailto:bre...@vi...]=20 Sent: Monday, February 23, 2004 5:36 PM To: cod...@li... Subject: [Codestriker-user] Perl-CPAN problems I am running RedHat Enterprise Server v3. While running ./checksetup.pl data is returned telling me to run: perl -MCPAN -e 'install "IPC::Run"' perl -MCPAN -e 'install "Template"' When executed; make: *** [test_dynamic] Error 29 is returned. Make test had returned bad status, won't install without force I am running Perl-5.8.0-88.4 and Perl-CPAN-1.61.88.4 Any ideas on how I can get past this. B Barker ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick _______________________________________________ Codestriker-user mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codestriker-user=20 =20 *************************************=20 This e-mail may contain privileged or confidential material intended for = the named recipient only.=20 If you are not the named recipient, delete this message and all = attachments.=20 Unauthorized reviewing, copying, printing, disclosing, or otherwise = using information in this e-mail is prohibited.=20 We reserve the right to monitor e-mail sent through our network. =20 *************************************=20 |
|
From: David S. <si...@us...> - 2004-02-24 01:52:33
|
On Tue, 24 Feb 2004 11:35, Barker, Brent wrote: > I am running RedHat Enterprise Server v3. While running ./checksetup.pl > data is returned telling me to run: > > perl -MCPAN -e 'install "IPC::Run"' > perl -MCPAN -e 'install "Template"' > > When executed; make: *** [test_dynamic] Error 29 is returned. > > Make test had returned bad status, won't install without forc Hmmm, I take it this message is from the IPC::Run module install? I did a quick search on the web, and noticed a similar error message. I'm not sure how critical this failed test is, I have not had issues with IPC::Run in production use. http://www.nntp.perl.org/group/perl.cpan.testers/12949 What version of IPC::Run is it trying to install? It might be worth following this up with the IPC::Run maintainer, and even trying a forced install. -- Cheers, David |
|
From: Barker, B. <bre...@vi...> - 2004-02-24 00:43:15
|
I am running RedHat Enterprise Server v3. While running ./checksetup.pl data is returned telling me to run: perl -MCPAN -e 'install "IPC::Run"' perl -MCPAN -e 'install "Template"' When executed; make: *** [test_dynamic] Error 29 is returned. Make test had returned bad status, won't install without force I am running Perl-5.8.0-88.4 and Perl-CPAN-1.61.88.4 Any ideas on how I can get past this. B Barker |
|
From: Matthew H. <mat...@wa...> - 2004-02-11 23:24:43
|
David, Your suggestion is what my secondary plan of action was going to be. The developers will just need to create a topic for each time that they commit, or do a diff between two revisions (beginning and end) and upload that file (notwithstanding potential changes from other developers will appear in the diff). This will have to be acceptable. :) Kelly's process of committing to particular branches would really break our current process. Not that your model isn't good, Kelly. It is just different than our very established way of branching and producing deliverables. :) Thanks for the discussion. It's interesting to learn how other organizations carry out the code review process. I look forward to 1.8.0! :) Matthew > There is an assumption in the Codestriker database that there=20 > is only a=20 > single diff change per filename in the patch file. Patch=20 > files (and diffs=20 > files from all SCM systems) have this property. I still=20 > maintain it would=20 > be confusing for a reviewer to see a diff chunk for more than=20 > one file,=20 > and then to see another diff chunk for the same file. The=20 > diff files you=20 > are talking about would have to be created by a custom tool,=20 > they can'tbe=20 > created by the SCM system. >=20 > A reviewer wants to see the cumulative code changes in one=20 > place, not in=20 > several places which would require them to mentally "merge"=20 > them together. =20 > Your provided example is very simple, and mental merging here=20 > is easy, but=20 > in a real-life scenario, I think it would be frustrating and=20 > error prone,=20 > especially if the second diff chunk makes changes made on the=20 > same lines=20 > of the first diff chunk. >=20 > What about the process Kelly describes? Does that suit your=20 > requirements=20 > better? Another option is before a developer does a commit=20 > for unreviewed=20 > code, they still post a Codestriker topic, but it gets reviewed at a=20 > future time. That way, if your process needs to commit code=20 > in the SCM=20 > now, you can still commit it, and it can get reviewed later,=20 > as the topic=20 > has been created. >=20 > --=20 > Cheers, > David >=20 >=20 =20 *************************************=20 This e-mail may contain privileged or confidential material intended for = the named recipient only.=20 If you are not the named recipient, delete this message and all = attachments.=20 Unauthorized reviewing, copying, printing, disclosing, or otherwise = using information in this e-mail is prohibited.=20 We reserve the right to monitor e-mail sent through our network. =20 *************************************=20 |
|
From: David S. <si...@us...> - 2004-02-11 22:46:23
|
> Basically, the only changes that I see that Codestriker would have to > make is how it parses the uploaded diff file. > > Currently each developer needs to: > - Create a diff file > - Create a Codestriker topic (upload their own diff file) > > This would remain the same with my scenario. The only difference would > be that the diff file uploaded in our scenario would contain multiple > entries of the same file with different revision diffs. There is an assumption in the Codestriker database that there is only a single diff change per filename in the patch file. Patch files (and diffs files from all SCM systems) have this property. I still maintain it would be confusing for a reviewer to see a diff chunk for more than one file, and then to see another diff chunk for the same file. The diff files you are talking about would have to be created by a custom tool, they can'tbe created by the SCM system. A reviewer wants to see the cumulative code changes in one place, not in several places which would require them to mentally "merge" them together. Your provided example is very simple, and mental merging here is easy, but in a real-life scenario, I think it would be frustrating and error prone, especially if the second diff chunk makes changes made on the same lines of the first diff chunk. What about the process Kelly describes? Does that suit your requirements better? Another option is before a developer does a commit for unreviewed code, they still post a Codestriker topic, but it gets reviewed at a future time. That way, if your process needs to commit code in the SCM now, you can still commit it, and it can get reviewed later, as the topic has been created. -- Cheers, David |
|
From: Kelly F. H. <kf...@mq...> - 2004-02-11 02:54:54
|
> -----Original Message----- > From: David Sitsky [mailto:si...@us...] > Sent: Tuesday, February 10, 2004 4:24 PM > To: Kelly F. Hickel; Matthew Hailstone; codestriker- > us...@li... > Subject: Re: [Codestriker-user] Feature request >=20 >=20 > > > The basic message is unreviewed code should never be committed to a > > > "public" branch that other developers are using. > > > > David, > > While I (in theory) agree with your last statement, we do have > > multiple developers working on projects (not always, but often), and so, > > they do share a branch. They are fully authorized to beat each other > > with a wet noodle if one of them breaks the other's code (;>), but it > > does happen. We do the reviews at the end, and sometimes the reviews > > cause changes, so we need to review it again, requiring a new > > codestriker topic, instead of just updating the existing one. >=20 > Ok, but in terms of reviewing code going into the main branch, you are > happy to review it as an ordinary diff file? >=20 > What Matthew is proposing is to create a diff file that contains separate > sections for each developer. Ahh, I missed that. No, what I want (which of course, translates to "the right thing" ;>) is to see all the chages on the branch rolled into one review screen. Ideally, each time I visited it, it would refresh to the latest set of changes on the branch. >=20 > -- > Cheers, > David See ya! -Kelly |
|
From: Matthew H. <mat...@wa...> - 2004-02-10 23:21:42
|
> Ok, but in terms of reviewing code going into the main=20 > branch, you are=20 > happy to review it as an ordinary diff file? >=20 Correct. Doing a diff on a modified file, producing the unified diff output and redirecting that output to a file, then uploading that file to a topic in Codestriker should accomplish this. > What Matthew is proposing is to create a diff file that=20 > contains separate=20 > sections for each developer. >=20 Your comment about a "diff file that contains separate sections for each developer" concerns me though. Basically, the only changes that I see that Codestriker would have to make is how it parses the uploaded diff file. Currently each developer needs to: - Create a diff file - Create a Codestriker topic (upload their own diff file) This would remain the same with my scenario. The only difference would be that the diff file uploaded in our scenario would contain multiple entries of the same file with different revision diffs. Index: append.test =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsrep/test/append.test,v retrieving revision 1.1 diff -u -r1.1 append.test --- append.test 6 Feb 2004 23:01:29 -0000 1.1 +++ append.test 6 Feb 2004 23:02:32 -0000 @@ -1,7 +1,7 @@ #This is a test test =3D 0 #To see how to append -append =3D 0 +append =3D 1 #Differential information from different revisions diffs =3D 0 #Into one diff file Index: append.test =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsrep/test/append.test,v retrieving revision 1.3 diff -u -r1.3 append.test --- append.test 6 Feb 2004 23:04:49 -0000 1.3 +++ append.test 6 Feb 2004 23:06:27 -0000 @@ -5,4 +5,4 @@ #Differential information from different revisions diffs =3D 1 #Into one diff file -file =3D 0 +file =3D 1 When the diff file is uploaded currently, the 1.3 diff is put under the 1.1 listing of the "append.test" file. I am suggesting that when the diff file is uploaded and parsed, that 2 listings are created for the "append.test" file (one for each occurrence in the diff file which will be different revision diffs). Each developer would still have to create their own diff file and create their own Codestriker topic. BTW, this has been a good exercise for me to evaluate myself in how well I'm communicating the problem. I hope I'm making more sense and not nonsense. Thanks! :) Matthew=20 =20 *************************************=20 This e-mail may contain privileged or confidential material intended for = the named recipient only.=20 If you are not the named recipient, delete this message and all = attachments.=20 Unauthorized reviewing, copying, printing, disclosing, or otherwise = using information in this e-mail is prohibited.=20 We reserve the right to monitor e-mail sent through our network. =20 *************************************=20 |
|
From: David S. <si...@us...> - 2004-02-10 22:24:56
|
> > The basic message is unreviewed code should never be committed to a > > "public" branch that other developers are using. > > David, > While I (in theory) agree with your last statement, we do have > multiple developers working on projects (not always, but often), and so, > they do share a branch. They are fully authorized to beat each other > with a wet noodle if one of them breaks the other's code (;>), but it > does happen. We do the reviews at the end, and sometimes the reviews > cause changes, so we need to review it again, requiring a new > codestriker topic, instead of just updating the existing one. Ok, but in terms of reviewing code going into the main branch, you are happy to review it as an ordinary diff file? What Matthew is proposing is to create a diff file that contains separate sections for each developer. -- Cheers, David |
|
From: Matthew H. <mat...@wa...> - 2004-02-10 21:51:32
|
David, I understand your suggestion. I agree with you that on the whole, code should be reviewed before committed. Unfortunately, I am still faced with the problem because other managers do not agree with that philosophy in all cases. Most of the time that will be the case, but because our processes are more time driven than event driven I'm coming up towards a brick wall with the scenario I described earlier. I am really excited about incorporating CodeStriker into our process, and except for this problem, everything is really going well. :) Here are the diff files that would be created in my scenario and my proposal: - Developer 1's diff file (developer1.diff) should look like the following: Index: append.test =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsrep/test/append.test,v retrieving revision 1.1 diff -u -r1.1 append.test --- append.test 6 Feb 2004 23:01:29 -0000 1.1 +++ append.test 6 Feb 2004 23:02:32 -0000 @@ -1,7 +1,7 @@ #This is a test test =3D 0 #To see how to append -append =3D 0 +append =3D 1 #Differential information from different revisions diffs =3D 0 #Into one diff file Index: append.test =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsrep/test/append.test,v retrieving revision 1.3 diff -u -r1.3 append.test --- append.test 6 Feb 2004 23:04:49 -0000 1.3 +++ append.test 6 Feb 2004 23:06:27 -0000 @@ -5,4 +5,4 @@ #Differential information from different revisions diffs =3D 1 #Into one diff file -file =3D 0 +file =3D 1 - Developer 2's diff file (developer2.diff) should look like the following: Index: append.test =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsrep/test/append.test,v retrieving revision 1.2 diff -u -r1.2 append.test --- append.test 6 Feb 2004 23:03:27 -0000 1.2 +++ append.test 6 Feb 2004 23:03:53 -0000 @@ -3,6 +3,6 @@ #To see how to append append =3D 1 #Differential information from different revisions -diffs =3D 0 +diffs =3D 1 #Into one diff file file =3D 0 Index: append.test =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsrep/test/append.test,v retrieving revision 1.4 diff -u -r1.4 append.test --- append.test 6 Feb 2004 23:05:27 -0000 1.4 +++ append.test 6 Feb 2004 23:05:34 -0000 @@ -1,5 +1,5 @@ #This is a test -test =3D 0 +test =3D 1 #To see how to append append =3D 1 #Differential information from different revisions - Now that both tasks have been completed, both developers would like to have each of their individual work reviewed. - Each developer creates a separate CodeStriker topic, and uploads/attaches their respective diff files. <Problem:> When a topic is created, only a single file entry is created for the "Contents:" list which is associated with the first encounter of the filename in the uploaded diff file. (i.e. Index: append.test) Subsequent entries of the same file are not associated with their respective revisions. All subsequent diff entries for an identified file entry is associated with the revision of the first encountered file entry. The "Parallel" and "non-Parallel?" views feature is also broken from this kind of diff file structure. <Possible Solution:>When parsing the uploaded diff file, create a new entry in the "Contents:" list for each file entry encountered in the diff file. This should also preserve revisioning and maintain the current "Parallel" and non-"Parallel" view functionality. If you try these kind of diff files, do you see the same problems happening? Thanks, :) Matthew=20 =20 *************************************=20 This e-mail may contain privileged or confidential material intended for = the named recipient only.=20 If you are not the named recipient, delete this message and all = attachments.=20 Unauthorized reviewing, copying, printing, disclosing, or otherwise = using information in this e-mail is prohibited.=20 We reserve the right to monitor e-mail sent through our network. =20 *************************************=20 |
|
From: Kelly F. H. <kf...@mq...> - 2004-02-10 21:25:02
|
> -----Original Message----- > From: David Sitsky [mailto:si...@us...] > Sent: Tuesday, February 10, 2004 3:22 PM > To: Kelly F. Hickel; Matthew Hailstone; codestriker- > us...@li... > Subject: Re: [Codestriker-user] Feature request >=20 > > Hi David, > > Just FYI, we don't do development this way, nor does any > > development organization that I've been a part of for the last 20 years. > > We do projects in branches, have the branches reviewed, do unit test, > > THEN merge it to the main line of development. We want our developers > > to be able to do a commit at any time (and urge them to do it at least > > daily) to prevent mishaps due to power outages, drive failure, etc. > > This has paid off more than once! The other issue arises when you're > > working on a change that affects several different platforms (aix, > > solaris and windows for instance), you need to be able to commit, so > > that you can check the code out on the other machines to do unit > > testing. >=20 > Hi Kelly, >=20 > I guess the key message here is that with your process, each developer has > their own separate _private_ branch, so even if they do daily commits to > their private branch, there is no impact to the rest of the development > team. With your process, there is still a way once the work has been > completed, to generate a diff that can be reviewed, and then merged with > the main branch. >=20 > With the process described by Matthew, unreviewed code from more than one > developer is being committed into a branch/main trunk, which I think is a > big problem. >=20 > The basic message is unreviewed code should never be committed to a > "public" branch that other developers are using. David, While I (in theory) agree with your last statement, we do have multiple developers working on projects (not always, but often), and so, they do share a branch. They are fully authorized to beat each other with a wet noodle if one of them breaks the other's code (;>), but it does happen. We do the reviews at the end, and sometimes the reviews cause changes, so we need to review it again, requiring a new codestriker topic, instead of just updating the existing one. -Kelly7 >=20 > -- > Cheers, > David |
|
From: David S. <si...@us...> - 2004-02-10 21:22:39
|
> Hi David, > Just FYI, we don't do development this way, nor does any > development organization that I've been a part of for the last 20 years. > We do projects in branches, have the branches reviewed, do unit test, > THEN merge it to the main line of development. We want our developers > to be able to do a commit at any time (and urge them to do it at least > daily) to prevent mishaps due to power outages, drive failure, etc. > This has paid off more than once! The other issue arises when you're > working on a change that affects several different platforms (aix, > solaris and windows for instance), you need to be able to commit, so > that you can check the code out on the other machines to do unit > testing. Hi Kelly, I guess the key message here is that with your process, each developer has their own separate _private_ branch, so even if they do daily commits to their private branch, there is no impact to the rest of the development team. With your process, there is still a way once the work has been completed, to generate a diff that can be reviewed, and then merged with the main branch. With the process described by Matthew, unreviewed code from more than one developer is being committed into a branch/main trunk, which I think is a big problem. The basic message is unreviewed code should never be committed to a "public" branch that other developers are using. -- Cheers, David |
|
From: Kelly F. H. <kf...@mq...> - 2004-02-10 13:11:21
|
> -----Original Message----- > From: David Sitsky [mailto:si...@us...] > Sent: Tuesday, February 10, 2004 4:16 AM > To: Matthew Hailstone; cod...@li... > Subject: Re: [Codestriker-user] Feature request >=20 > > - Now that both tasks have been completed, both developers would like to > > have each of their individual work reviewed. >=20 > This is the problem. Codestriker is designed to be a "pre-commit" step. >=20 > The usual scenario with development teams is that unreviewed code is _not_ > allowed to be committed into the CVS repository. Once code has been > reviewed, then the developer is free to commit it in. >=20 > The motivation for this is that a bad commit can impact the whole > development > team, resulting in potentially a lot of wasted time for bad commits. Hi David, Just FYI, we don't do development this way, nor does any development organization that I've been a part of for the last 20 years. We do projects in branches, have the branches reviewed, do unit test, THEN merge it to the main line of development. We want our developers to be able to do a commit at any time (and urge them to do it at least daily) to prevent mishaps due to power outages, drive failure, etc. This has paid off more than once! The other issue arises when you're working on a change that affects several different platforms (aix, solaris and windows for instance), you need to be able to commit, so that you can check the code out on the other machines to do unit testing. -Kelly >=20 > In your scenario, there should be no commits by developer 1 or 2. Once > they > have finished their "work", then they produce a "cvs diff" which is then > reviewed in Codestriker. >=20 > There is no problem with both reviewers doing this in parallel - CVS is > designed to handle this merges and so forth. >=20 > The challenge is to define sensible units of work, which aren't too large > to > review, but software teams become very experienced at doing this very > quickly. >=20 > Cheers, > David >=20 >=20 > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Codestriker-user mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codestriker-user |
|
From: David S. <si...@us...> - 2004-02-10 10:32:35
|
> - Now that both tasks have been completed, both developers would like to > have each of their individual work reviewed. This is the problem. Codestriker is designed to be a "pre-commit" step. The usual scenario with development teams is that unreviewed code is _not_ allowed to be committed into the CVS repository. Once code has been reviewed, then the developer is free to commit it in. The motivation for this is that a bad commit can impact the whole development team, resulting in potentially a lot of wasted time for bad commits. In your scenario, there should be no commits by developer 1 or 2. Once they have finished their "work", then they produce a "cvs diff" which is then reviewed in Codestriker. There is no problem with both reviewers doing this in parallel - CVS is designed to handle this merges and so forth. The challenge is to define sensible units of work, which aren't too large to review, but software teams become very experienced at doing this very quickly. Cheers, David |
192 messages has been excluded from this view by a project administrator.
