Menu
▾
▴
|
From: <msc...@ao...> - 2003-01-31 04:39:06
|
In a message dated 1/30/2003 8:00:07 PM Eastern Standard Time, Kevin Goess <ke...@go...> writes:
>But I already checked a bunch of other work I'm doing on the XML-DOM
>into 0.29 which isn't ready to be released yet. Just to this in your
Problem is that the CPAN release needs a new version number. We can't re-release 0.28. One option would be to call it 0.281 but that's a risky thing to do on CPAN, that could break all kinds of things (ordering etc.). Can't you revert your checkins so we get a clean 0.29 real quick?
>Umm, how do we test if the module isn't there?
squirrel is your friend:
http://www.perlmeister.com/scripts/squirrel-README.html
http://www.perlmeister.com/scripts/squirrel
--
-- Mike
############################
# Mike Schilli #
# log...@pe... #
# http://perlmeister.com #
# log4perl.sourceforge.net #
############################
|
|
From: <Msc...@ao...> - 2003-01-31 05:20:46
|
In a message dated 1/30/2003 11:38:50 PM Eastern Standard Time, msc...@ao... writes: >Problem is that the CPAN release needs a new version number. Never mind, I got confused :). I've just release 0.29 to the web site, based on your branch. Please verify and merge your stuff to the tip. -- Mike ############################ # Mike Schilli # # log...@pe... # # http://perlmeister.com # # log4perl.sourceforge.net # ############################ |
|
From: Kevin G. <ke...@go...> - 2003-01-31 17:07:26
|
Msc...@ao... wrote:
>> Problem is that the CPAN release needs a new version number.
>
> Never mind, I got confused :). I've just release 0.29 to the web
> site, based on your branch.
There ya go! That's what I was getting at.
What was the final disposition of the 017Watch.t test? My position
would be that if we can't trust the timestamps on the filesystem, the
whole init_and_watch system is going to break down. We wouldn't be able
to do
if ( ($LAST_CHECKED_AT + $WATCH_DELAY) < time()){
because there's no relation between time() and stat($FILE_TO_WATCH).
Instead of calling time(), you'd have to touch a file on the filesystem,
in effect asking the filesystem what time *it* thinks it is now.
So I think we should leave 036JSyslog.t as it is. Drifing times on an
NFS mount should actually cause a failure (they'll bollix other things
to, like tar for instance--ntp synchronization is a very good idea for
NFS situations ).
And what was the final disposition of 036JSyslog.t? I just changed it
to always succeed. That way it won't keep log4perl from installing, but
it will give some indication to the user whether they can expecte syslog
logging to work on their system. I just did that right now, so you'll
need to update the web site (you didn't send to cpan yet, right?)
> Please verify and merge your stuff to the
> tip.
Done! But I'll wait till the end of the day to check it in.
--
Happy Trails . . .
Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA 94706
(510) 525-5217
|
|
From: <Msc...@ao...> - 2003-01-31 17:49:15
|
In a message dated 1/31/03 9:07:40 AM Pacific Standard Time, ke...@go... writes: > What was the final disposition of the 017Watch.t test? My position > would be that if we can't trust the timestamps on the filesystem, the > whole init_and_watch system is going to break down. There's two different things to consider: Initial offset and continuous drift. Without really having looked at the code, I would suspect that we could easily resolve the first item by determinining the offset the first time around. My concern was just that if you've got a file system that's a bit off (like the one I was using), the Log::Log4perl test suite will fail. This is not of immediate concern, though, I'll keep it on the TODO list. > And what was the final disposition of 036JSyslog.t? I just changed it > to always succeed. That way it won't keep log4perl from installing, but > it will give some indication to the user whether they can expecte syslog > logging to work on their system. I just did that right now, so you'll > need to update the web site (you didn't send to cpan yet, right?) It's not on CPAN yet. I'm not too happy with the change -- my experiments just showed warnings, same warnings as you get when installing Log::Dispatch. It wasn't breaking the test suite. Ok if we leave 036JSyslog.t as it was for now? -- Mike Mike Schilli log...@pe... |
|
From: Kevin G. <ke...@go...> - 2003-01-31 19:36:23
|
> > It's not on CPAN yet. I'm not too happy with the change -- my > experiments just showed warnings, same warnings as you get when > installing Log::Dispatch. It wasn't breaking the test suite. Ok if we > leave 036JSyslog.t as it was for now? Oh, I see, I thought it was a failure. Sure, leave it as it is. -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |
|
From: <Msc...@ao...> - 2003-01-31 20:33:01
|
In a message dated 1/31/03 11:40:36 AM Pacific Standard Time, ke...@go... writes: > Oh, I see, I thought it was a failure. Sure, leave it as it is. Ok, I've refreshed the webpage one more time with 0.29 -- I'm gonna run some tests tonight and if it looks ok, I'm gonna send it off to CPAN. Any hickups, let me know ... -- Mike Mike Schilli log...@pe... |
|
From: Kevin G. <ke...@go...> - 2003-01-31 17:14:53
|
msc...@ao... wrote: > In a message dated 1/30/2003 8:00:07 PM Eastern Standard Time, Kevin > Goess <ke...@go...> writes: >> Umm, how do we test if the module isn't there? > > squirrel is your friend: > > http://www.perlmeister.com/scripts/squirrel-README.html > http://www.perlmeister.com/scripts/squirrel Ahh, I see what you're getting at. Very interesting. I'll see what I can do with that. -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |
