1. SCons
  2. Core
  3. SCons

Wiki

Clone wiki

SCons / BugParty / IrcLog2009-12-01

16:02:51  *      sgk (n=stevenkn@nat/google/x-ncfwmskxkmsbaijr) has joined #scons 
17:00:59  <sgk>  anyone else here yet for bug party? 
17:01:48  *      You are no longer marked as being away 
17:02:05  <[GregNoel](GregNoel)>     Hi, Steven, just got here; give me a minute to set up. 
17:04:39  <sgk>  np, i'm still getting set up myself 
17:05:57  *      sgk really needs to install colloquy 
17:06:41  <[GregNoel](GregNoel)>     What's that?  Some flavor of wave? 
17:07:18  <sgk>  better mac irc client than x-chat aqua 
17:07:34  <sgk>  i've installed it on my desktop mac at work, but not my macbook 
17:07:43  <[GregNoel](GregNoel)>     Why is it better? 
17:12:27  <[GregNoel](GregNoel)>     Where is everybody? 
17:13:07  <sgk>  yeah, where is everyone?  i know bill's on a plane, but i thought for sure garyo would be here 
17:13:25  <[GregNoel](GregNoel)>     ditto 
17:13:29  *      sgk sighs 
17:14:56  <sgk>  then i say we just start assigning all the issues to garyo+bdbaddog+Jason_at_intel in rotation 
17:15:07  <[GregNoel](GregNoel)>     worksforme 
17:18:26  <[GregNoel](GregNoel)>     We can talk a bit about QMTest if you want.  I have a couple of things I want to mention. 
17:19:43  <sgk>  sure 
17:19:48  <[GregNoel](GregNoel)>     About QMTest (and SCons testing in general): 
17:19:48  <[GregNoel](GregNoel)>     In brief, I think we should drop QMTest, for all of the reasons Steven said in his message, and more.  I think that it would only take a few modifications to runtest.py to get a better display like QMTest, and we could probably do more.  I've been looking at making this sort of change, but I think a revised configure and new Taskmaster are more important, so I haven't said anything. 
17:19:48  <[GregNoel](GregNoel)>     I think unittest should be made a base class for the SConsTest hierarchy, making those functions available for integrated tests as well. 
17:19:48  <[GregNoel](GregNoel)>     I think tests should always make a positive assertion about what happened, so we don't get any more of those cases where flow accidentally runs off the bottom. 
17:19:48  <[GregNoel](GregNoel)>     I think the tests should be timed, and the times reported. 
17:19:48  <[GregNoel](GregNoel)>     I think there should be a timeout on the tests, so if they run more than NNN seconds (start with 300 and move down) the test is aborted. 
17:19:48  <[GregNoel](GregNoel)>     I think there should be four types of test returns: 
17:19:48  <[GregNoel](GregNoel)>     -1- PASSED meaning that the test was run and everything succeeded. 
17:19:48  <[GregNoel](GregNoel)>     -2- UNRUNABLE meaning that the test was not run and nothing can be done to make it work on this hardware/OS combination (e.g., wrong OS, wrong instruction set, wrong Python version, whatever) 
17:19:48  <[GregNoel](GregNoel)>     -3- NO RESULT meaning that the test was not run, but some change to the environment would allow it to be run (e.g., TeX not present but could be, old version of SWIG, VS not installed, whatever) 
17:19:48  <[GregNoel](GregNoel)>     -4- FAILED meaning that the test was run and found some problem. 
17:19:48  <[GregNoel](GregNoel)>     The last two should be summarized (separately!) at the end of the run. 
17:19:48  <[GregNoel](GregNoel)>     (I've been practicing my typing speed; how'm I doing?) 
17:21:25  <sgk>  impressive! 
17:22:11  <sgk>  seems reasonable to me 
17:23:00  <[GregNoel](GregNoel)>     I suppose I should write it up in a design note in the wiki, now that I've written it once already. 
17:23:08  <sgk>  not a bad idea 
17:23:01  *      garyo (n=[garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com](mailto:garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)) has joined #scons 
17:23:08  <[GregNoel](GregNoel)>     Ah-HA! 
17:23:15  <garyo>        Hi guys 
17:23:23  <[GregNoel](GregNoel)>     A bit late, are we? 
17:23:30  <sgk>  i have to run to the shuttle, i'll be back on after it shows up in ~5 - 10 minutes 
17:23:34  *      sgk has quit ("This computer has gone to sleep") 
17:23:46  <[GregNoel](GregNoel)>     Good timing, I guess... 
17:23:54  <garyo>        sorry, too much kids stuff 
17:24:09  <garyo>        what'd I miss? 
17:24:12  <[GregNoel](GregNoel)>     Just some QMTest stuff. 
17:24:16  <[GregNoel](GregNoel)>     So, would you like to chat about QMTest while we're waiting for Steven to get back? 
17:24:21  <garyo>        ok 
17:24:25  <[GregNoel](GregNoel)>     About QMTest (and SCons testing in general): 
17:24:25  <[GregNoel](GregNoel)>     In brief, I think we should drop QMTest, for all of the reasons Steven said in his message, and more.  I think that it would only take a few modifications to runtest.py to get a better display like QMTest, and we could probably do more. I've been looking at making this sort of change, but I think a revised configure and new Taskmaster are more important, so I haven't said anything. 
17:24:25  <[GregNoel](GregNoel)>     I think unittest should be made a base class for the SConsTest hierarchy, making those functions available for integrated tests as well. 
17:24:25  <[GregNoel](GregNoel)>     I think tests should always make a positive assertion about what happened, so we don't get any more of those cases where flow accidentally runs off the bottom. 
17:24:25  <[GregNoel](GregNoel)>     I think the tests should be timed, and the times reported. 
17:24:25  <[GregNoel](GregNoel)>     I think there should be a timeout on the tests, so if they run more than NNN seconds (start with 300 and move down) the test is aborted. 
17:24:25  <[GregNoel](GregNoel)>     I think there should be four types of test returns: 
17:24:25  <[GregNoel](GregNoel)>     -1- PASSED meaning that the test was run and everything succeeded. 
17:24:25  <[GregNoel](GregNoel)>     -2- UNRUNABLE meaning that the test was not run and nothing can be done to make it work on this hardware/OS combination (e.g., wrong OS, wrong instruction set, wrong Python version, whatever) 
17:24:25  <[GregNoel](GregNoel)>     -3- NO RESULT meaning that the test was not run, but some change to the environment would allow it to be run (e.g., TeX not present but could be, old version of SWIG, VS not installed, whatever) 
17:24:25  <[GregNoel](GregNoel)>     -4- FAILED meaning that the test was run and found some problem. 
17:24:25  <[GregNoel](GregNoel)>     The last two should be summarized (separately!) at the end of the run. 
17:24:25  <[GregNoel](GregNoel)>     (I've been practicing my typing speed; how'm I doing?) 
17:25:04  <garyo>        :-) 
17:25:40  <garyo>        re: dropping qmtest in general, I'm fine with it.  Don't think it provides us much more than a simpler python test fwk. 
17:25:59  <[GregNoel](GregNoel)>     (fwk?) 
17:26:04  <garyo>        framework 
17:26:09  <[GregNoel](GregNoel)>     Ah. 
17:26:23  <[GregNoel](GregNoel)>     I agree. 
17:26:40  <garyo>        Probably most of what we use QMtest for is in the higher-level TestSCons etc. classes anyway. 
17:26:58  <[GregNoel](GregNoel)>     Yeah, I think so, too. 
17:26:45  <[GregNoel](GregNoel)>     QMTest has a lot going for it, but we use so little of it. 
17:27:22  <garyo>        agreed.  However, to get to *all* of what you propose is perhaps a big project.  Still, that shouldn't stop us from getting started. 
17:27:39  <[GregNoel](GregNoel)>     One step at a time. 
17:27:49  <garyo>        (Like timing, timeouts, new & interesting reports, etc.) 
17:28:29  <[GregNoel](GregNoel)>     The timeout is primarily for [KeyboardInterrupt](KeyboardInterrupt) which still stalls now and again. 
17:28:24  <garyo>        So we just make --noqmtest the default, right?  That's the 1st step? 
17:28:48  <[GregNoel](GregNoel)>     I think so; it gets rid of a diagnostic. 
17:29:03  <garyo>        yes, I've seen it.  That kind of thing will be easier with subprocess support I think (?) 
17:29:26  <garyo>        So this would be a post-1.3 thing? 
17:29:54  <[GregNoel](GregNoel)>     Post 1.3, yes.  Newer Python constructs will help. 
17:30:51  *      sgk (n=[stevenkn@67.218.106.196](mailto:stevenkn@67.218.106.196)) has joined #scons 
17:30:57  <[GregNoel](GregNoel)>     I should write up a wiki page, now that I've written it once already.  Sigh, yet more words cast into the blue. 
17:30:58  <garyo>        sounds good. I also like it because although it's a big project it has lots of little parts that people can bite off now & then, unlike some of the more central things (toolchain, tmng, etc.) 
17:31:02  <sgk>  back.  what'd i miss? 
17:31:15  <[GregNoel](GregNoel)>     Continuing on QMTest. 
17:31:17  <garyo>        Hi, Greg just gave me his =noqmtest spiel 
17:31:22  <garyo>        :-) 
17:31:22  <sgk>  cool 
17:31:28  <garyo>        I basically agree 
17:31:38  <sgk>  i basically agree too 
17:31:46  <garyo>        just take it in small steps 
17:31:32  <sgk>  couple comments / questions 
17:31:53  <sgk>  clarification:  perceived advantage of unittest as base? 
17:31:59  <sgk>  i have mixed emotions about unittest 
17:32:16  <garyo>        Our QA person is using it here; I can ask her what she thinks of it. 
17:32:30  <garyo>        I think we do want *some* framework underneath. 
17:32:48  <[GregNoel](GregNoel)>     It has some useful functions, some duplicated in the [TestScons](TestScons) stack; harmless at worst if we're keeping it as a basis for unit tests. 
17:33:03  <sgk>  my main hesitation is that our system tests aren't unit tests in the classic sense 
17:33:20  <garyo>        Does that matter? 
17:33:21  <sgk>  concerned that shoehorning them into an unsuitable framework may mislead people or have other drawbacks 
17:33:26  <[GregNoel](GregNoel)>     The system tests, no, but it doesn't matter. 
17:33:28  <sgk>  not sure if it does or not 
17:33:32  <[GregNoel](GregNoel)>     jinx 
17:33:58  <garyo>        Is there an alternative fwk? 
17:34:13  <sgk>  homebrew, which is one of the reasons unittest is attractive 
17:34:38  <garyo>        Right, let's not reinvent the wheel. 
17:34:41  <sgk>  but what does the underlying framework buy us over homebrew? 
17:35:31  <[GregNoel](GregNoel)>     Actually, the major reason I suggested it is that I'd like some of the TestSCons functions in unittest, so make it a base class of some class there; once you've done that, you may as well make it a base class overall. 
17:34:59  <garyo>        A long time ago I remember looking at 'nose' which did some more auto-discovery. 
17:35:03  <garyo>        (compared to unittest) 
17:36:12  <garyo>        [http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy](http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy) has a big list. 
17:36:25  <[GregNoel](GregNoel)>     Anyway, I'll write it up in my copious spare time. 
17:36:36  <sgk>  well, i've already done some adaptation of [TestCmd](TestCmd) + [TestCommon](TestCommon) to gtest (google's flavor of unittest) 
17:37:06  <sgk>  so it wouldn't be too bad to do unittest itself 
17:36:48  <garyo>        what does it buy us?  IMHO, reporting is big, plus lots of assertions, exception handling, etc. 
17:37:40  <sgk>  well, that's what i don't get.  it wouldn't be too hard to just have a unittest wrapper that executes our current scripts 
17:38:10  <sgk>  but all of the failure conditions and the like don't lend themselves to the inside-the-functiona sserts that unittest gives you 
17:38:31  <[GregNoel](GregNoel)>     Not to be a wet blanket, but we should triage some bugs. 
17:38:53  <sgk>  (garyo, good link re: test taxonomy) 
17:39:10  <[GregNoel](GregNoel)>     ditto 
17:39:28  <[GregNoel](GregNoel)>     I've already bookmarked it. 
17:39:21  <sgk>  fair enough, let's table the test specifics and get to the bugs 
17:39:23  <garyo>        ok, just one more round -- asserts are possibly less valuable then than the reporting -- how many failures, which tests failed.  I just want to be able to find the failure as easily as possible and go reproduce it. 
17:39:35  <garyo>        ok, I'm ready 
17:39:56  <[GregNoel](GregNoel)>     2446 reprise 
17:40:00  <garyo>        2446: remove that line? 
17:40:19  <[GregNoel](GregNoel)>     I think so.  It doesn't appear to be used. 
17:40:28  <garyo>        ok, done.  I'll do it, assign it to me. 
17:40:37  <[GregNoel](GregNoel)>     done; thanks 
17:41:09  <sgk>  concur, it looks unnecessary 
17:41:09  <[GregNoel](GregNoel)>     2485 
17:41:16  <garyo>        research garyo 
17:41:36  <[GregNoel](GregNoel)>     done 
17:41:55  <[GregNoel](GregNoel)>     2469 consensus 
17:41:59  <garyo>        yup 
17:42:09  <sgk>  agree 
17:42:19  <[GregNoel](GregNoel)>     2470 
17:43:16  <[GregNoel](GregNoel)>     Is it something that should be fixed? 
17:42:25  <garyo>        2470: I asked OP for more details, he didn't have a user-level failure associated with it. 
17:42:27  <sgk>  garyo already asked 
17:42:57  <garyo>        He'd like to know if there is a better way to get the variant dir associated with a source dir. 
17:43:35  <[GregNoel](GregNoel)>     Dir('.')? 
17:43:02  <sgk>  no user failure => invalid, i think 
17:43:22  <[GregNoel](GregNoel)>     yes, invalid. 
17:44:02  <sgk>  he should be able to query a node directly for that 
17:44:14  <sgk>  oh, wait 
17:44:18  <garyo>        But... the code does look suspicious.  Seems like his fix is valid in the abstract; maybe everything works OK today just because nobody calls alter_targets with paths like his. 
17:44:27  <sgk>  that's one of those issues where there's no "the" variant dir 
17:44:35  <sgk>  you could be building multiple variants 
17:44:59  <garyo>        Right, he wants to go the reverse direction (as it were). 
17:45:26  <garyo>        I don't really want to make an API for him to do it, I just want to make adjust_targets do what it's supposed to do. 
17:45:30  <garyo>        (whatever that is) 
17:45:43  <garyo>        adjust -> alter, sorry 
17:45:43  <[GregNoel](GregNoel)>     Best he can do is get the current variant dir, using Dir(). 
17:45:57  <garyo>        I'll mention that to him. 
17:46:31  <sgk>  k, invalid, garyo follows up with Dir('.") 
17:46:36  <[GregNoel](GregNoel)>     Since Gary's already on it, let him run with it and report back next time? 
17:46:45  <garyo>        well, ok. 
17:46:54  <[GregNoel](GregNoel)>     done 
17:47:23  <[GregNoel](GregNoel)>     2471 
17:47:59  <[GregNoel](GregNoel)>     It seems like future is too far out; I'd like it sooner. 
17:48:36  <[GregNoel](GregNoel)>     Searching also needs a magic token for "dir of source file" 
17:47:36  <sgk>  is it real or theoretical? 
17:47:43  <garyo>        It's real. 
17:47:55  <garyo>        <> never searches the current dir. 
17:47:58  <sgk>  which compiler(s)? 
17:48:05  <garyo>        gcc, msvc. 
17:48:32  <sgk>  ?  if <> doesn't do that it's a regression 
17:48:31  <garyo>        So if you have a stdio.h in the current dir, scons will think that's the one you mean, but the compiler won't. 
17:48:42  <sgk>  oh 
17:49:17  <garyo>        In the limit it's quite complicated though (and compiler-specific). 
17:50:01  <[GregNoel](GregNoel)>     It's well into undefined territory in the C/C++ spec, but the convention seems common. 
17:49:04  <sgk>  that sounds like an outright bug in the behavior then 
17:49:27  <sgk>  that can just be fixed in the current code 
17:50:05  <garyo>        I agree, I don't think it's a huge deal as long as we know which kind of include it is 
17:50:31  <sgk>  so perhaps change scons' <> search in the current code for the short term 
17:50:43  <garyo>        I'd be happy w/ that. 
17:50:55  <sgk>  and a future to invent a CPPPATH replacement that allows separate "" vs. <> configuration? 
17:51:00  <garyo>        (It's not perfect but better than today) 
17:51:07  <[GregNoel](GregNoel)>     If we can do that short term, pushing the general case to future is fine with me. 
17:51:44  <garyo>        ok, steven 2.x p? 
17:51:47  <[GregNoel](GregNoel)>     OK, what priority on the short case? 
17:51:56  <garyo>        p3? 
17:52:01  <[GregNoel](GregNoel)>     works 
17:52:20  <[GregNoel](GregNoel)>     What priority when it goes into the future? 
17:52:26  <sgk>  if the current code doesn't mimic gcc + msvc practice, then i think any backwards compatibility issues are negligible; let's change it 
17:53:05  <garyo>        I'd say p4 for the future because people won't usually even notice. 
17:53:08  <sgk>  maybe 2.0 p2 for the short term fix 
17:53:12  <sgk>  future p3 for the long term 
17:54:00  <[GregNoel](GregNoel)>     Agree w/ Steven 
17:53:49  <garyo>        either way, I'm fine w/ p2/p3 or p3/p4.  I guess I lean toward p3/p4 just because there's a lot of other stuff to do 
17:53:32  <[GregNoel](GregNoel)>     And note that '.' isn't right for the local search path; it's "directory of source file" 
17:54:14  <garyo>        Greg: I'm not sure gcc and msvc agree 100% there. 
17:54:47  <garyo>        I think one of them uses the dir of the source file, the other uses the dir of the including file (but I ould be wrong) 
17:55:55  <[GregNoel](GregNoel)>     Same thing; it's relative to the file that includes it. 
17:54:34  <[GregNoel](GregNoel)>     Oops, Steven said 2.0.  It should be 2.x. 
17:54:43  <sgk>  okay, 2.x 
17:54:49  <[GregNoel](GregNoel)>     2.x p2 then future p3 
17:54:55  <sgk>  done 
17:54:55  <garyo>        fine 
17:55:04  <[GregNoel](GregNoel)>     done 
17:55:23  <garyo>        2472 I already closed 
17:55:26  <[GregNoel](GregNoel)>     done 
17:55:31  <garyo>        & 2473 
17:55:37  <garyo>        hope you guys don't mind 
17:55:38  <[GregNoel](GregNoel)>     ++ 
17:55:40  <sgk>  garyo++ 
17:56:07  <[GregNoel](GregNoel)>     2474 
17:56:17  <sgk>  research, who? 
17:56:37  <sgk>  sign up bdbaddog? 
17:56:40  <garyo>        don't know, not me 
17:56:42  <[GregNoel](GregNoel)>     I don't think research is right 
17:57:18  <garyo>        Well, we don't know what's going on... 
17:57:20  <[GregNoel](GregNoel)>     We know about the problem with directories; there's even a SEP about it. 
17:57:20  <sgk>  seems like it needs some characterization...  back to op? 
17:57:47  <garyo>        "back to op" to me is a lot like "research" 
17:58:50  <[GregNoel](GregNoel)>     Seeing no consensus, pass to next time. 
17:59:00  <garyo>        OK w/ me. 
17:59:01  <[GregNoel](GregNoel)>     2475 
17:59:14  <[GregNoel](GregNoel)>     consensus 
17:59:28  <[GregNoel](GregNoel)>     2476 
17:59:52  <sgk>  ok 
18:00:07  <garyo>        option 1 seems good to me. 
18:00:19  <[GregNoel](GregNoel)>     I disagree with second option; some values cannot be modified (platform, for one) 
18:00:26  <[GregNoel](GregNoel)>     For the others, maybe. 
18:00:37  <garyo>        all the more reason to take option 1 :-) 
18:01:30  <sgk>  okay, first option is fine with me 
18:01:14  <[GregNoel](GregNoel)>     OK, I'll include a commentary; 2.x p4 who? 
18:01:37  <garyo>        Greg, maybe you could do it?  Or Bill? 
18:01:48  <[GregNoel](GregNoel)>     Or for 2.x, not a strong motivation to assign an owner now. 
18:02:07  <garyo>        ok, esp. w/ +Easy 
18:02:16  <sgk>  agree 
18:02:35  <[GregNoel](GregNoel)>     done 
18:02:18  <[GregNoel](GregNoel)>     Actually, a lot of it should be subsumed by revamped configure. 
18:02:35  <garyo>        and/or toolchain 
18:02:41  <sgk>  right 
18:02:48  <[GregNoel](GregNoel)>     Er, yes, that's what I meant. 
18:03:01  <[GregNoel](GregNoel)>     Closely related in my mind. 
18:02:57  <garyo>        2477: 2.1 p2 bdbaddog 
18:03:08  <[GregNoel](GregNoel)>     done 
18:03:23  <sgk>  2478:   2.x p3 bdbaddog 
18:03:27  <[GregNoel](GregNoel)>     done 
18:03:53  <sgk>  2479:  ask OP if he'd like to contribute 
18:03:56  <garyo>        2479: invalid, unless OP wants to work on it 
18:04:06  <[GregNoel](GregNoel)>     How can it be invalid+symlink? 
18:04:17  <sgk>  ? 
18:04:51  <garyo>        1: ask OP if he's interested.  If yes, then it's him +symlink.  Else, invalid & close. 
18:04:51  <[GregNoel](GregNoel)>     If it's invalid, it goes away.  If it's +symlink, it's assigned with the other symlink issues. 
18:05:00  <garyo>        jinx 
18:05:08  <[GregNoel](GregNoel)>     concur w/ garyo 
18:05:14  <sgk>  oh, i see 
18:05:36  <sgk>  done 
18:05:40  <[GregNoel](GregNoel)>     done 
18:05:44  <garyo>        2480: research bdbaddog 
18:05:52  <sgk>  go badbaddog! 
18:05:58  <[GregNoel](GregNoel)>     done 
18:05:57  <garyo>        2481: already fixed. 
18:06:28  <[GregNoel](GregNoel)>     2481 done 
18:06:38  <[GregNoel](GregNoel)>     2482 
18:07:09  <garyo>        how about mark as future, hope it goes away w/ sconf revamp? 
18:06:57  <sgk>  2482 is hairy; no obvious course of action; defer to next time? 
18:07:16  <sgk>  lame, I know, but i don't think time here on it is productive 
18:07:20  <[GregNoel](GregNoel)>     yeah, I'll look at it between now and then 
18:07:21  <garyo>        agreed. 
18:07:27  <sgk>  done 
18:07:33  <[GregNoel](GregNoel)>     2483 
18:07:46  <sgk>  2.x p3 bdbaddog 
18:08:04  <sgk>  w/note re: clarifying whether the behavior is specific 
18:08:11  <garyo>        sounds good. 
18:08:29  <[GregNoel](GregNoel)>     OK.  (There's really only one java compiler, short of what GNU is doing, and we don't support that yet.) 
18:08:48  <sgk>  ?  there's sun, there's blackdown, there's gcj... 
18:09:31  <sgk>  anyway 
18:09:33  <garyo>        Not my world.  Let me know when any of them can process 33Mpixels in 16msec. 
18:09:37  <[GregNoel](GregNoel)>     gcj is GNU, I don't know what its command line is like; blackdown follows Sun as far as I know. 
18:09:51  <garyo>        ok, let's keep moving... 2484 
18:09:54  <sgk>  2484:  2.1 p2 bdbaddog 
18:10:03  <garyo>        good. 
18:10:22  <[GregNoel](GregNoel)>     done 
18:10:32  <garyo>        2486: Steven, can you take that one? 
18:10:45  <sgk>  okay 
18:10:57  <sgk>  still 2.x p2 ? 
18:11:10  <sgk>  sure 
18:11:16  <garyo>        Sure (or p3, your call) 
18:10:47  <[GregNoel](GregNoel)>     done 
18:11:27  *      sgk has about 5 minutes to the shuttle stop 
18:11:42  <[GregNoel](GregNoel)>     2487, wontfix 
18:11:43  <sgk>  2.x p3 stevenknight 
18:11:47  <garyo>        2487: let's mark invalid.  The filter idea we can take up later. 
18:11:48  <sgk>  done 
18:12:05  <[GregNoel](GregNoel)>     ok, invalid 
18:12:09  <sgk>  2488:  2.x p2 bdbaddog 
18:12:19  <garyo>        yep 
18:12:24  <[GregNoel](GregNoel)>     done 
18:12:42  <garyo>        2489: future or 2.x?  Maybe 3.x? 
18:12:59  <[GregNoel](GregNoel)>     I don't use it; no opinion 
18:13:09  <sgk>  3.x sounds about right 
18:13:15  <sgk>  2.x would be nice, but there's already enough there 
18:13:20  <[GregNoel](GregNoel)>     too much 
18:13:25  <garyo>        It would take me a while to refactor my code to use it too.  Agree w/ Steven re: 3.x. 
18:13:31  <[GregNoel](GregNoel)>     p? 
18:13:34  <garyo>        3 
18:13:37  <sgk>  p3 
18:13:39  <[GregNoel](GregNoel)>     done 
18:13:54  <garyo>        2490: I asked for a patch.  We'll see. 
18:14:01  <[GregNoel](GregNoel)>     defer to next time 
18:14:02  <sgk>  2490:  is it passible he just added a C# module somewhere? 
18:14:07  <sgk>  defer++ 
18:14:21  <garyo>        steven: definitely possible. 
18:14:39  <sgk>  i may take a look for the module while waiting for tests to run 
18:14:39  <garyo>        2491: anytime p4 sounds fine. 
18:14:51  <sgk>  anytime p4 
18:15:02  <[GregNoel](GregNoel)>     done 
18:15:11  <[GregNoel](GregNoel)>     oops, er, who? 
18:15:41  <[GregNoel](GregNoel)>     anytime needs an owner 
18:15:09  <garyo>        sgk: or you could knock of a +Easy one... better way to spend the time perhaps? 
18:15:11  <garyo>        :-) 
18:15:40  <garyo>        Steven, I think only you understand the packaging stuff well enough I think. 
18:15:50  <sgk>  garyo:  feel free to prioritize my time that way... 
18:15:54  <[GregNoel](GregNoel)>     I sure don't 
18:16:03  <sgk>  okay, me 
18:16:14  <[GregNoel](GregNoel)>     done 
18:16:55  <garyo>        btw speaking of time & priorities you have been very productive recently -- good to see! 
18:16:49  <[GregNoel](GregNoel)>     2492, assign to rob? 
18:17:03  <sgk>  2492:  could be draconian and also mark it fixed with invitation to re-open if that's hasty 
18:17:19  <garyo>        2492: agree w/ steven 
18:17:36  <[GregNoel](GregNoel)>     yes, concur.  done 
18:17:55  <garyo>        2493 consensus 
18:17:58  <[GregNoel](GregNoel)>     done 
18:17:59  <sgk>  done 
18:18:14  <sgk>  2494 anytime +Easy 
18:18:24  <[GregNoel](GregNoel)>     then who? 
18:18:40  <sgk>  doesn't +Easy mean it doesn't need a who? 
18:18:41  <garyo>        if we need an owner for an anytime, then I'd say 2.x or 3.x instead. 
18:18:51  <sgk>  okay, 2.x 
18:19:04  <sgk>  anything to avoid the dread "who?" question... :-) 
18:19:12  <[GregNoel](GregNoel)>     Hmmm... you're right, we have some +Easy anytime 
18:19:13  <garyo>        sgk: I think that makes sense, anytime +Easy no owner is fine w/ me. 
18:19:26  <sgk>  okay, anytime 
18:19:25  <[GregNoel](GregNoel)>     done 
18:19:41  *      sgk has < 1 minute 
18:19:46  <garyo>        2495 is for me 
18:19:50  <sgk>  done 
18:19:55  <[GregNoel](GregNoel)>     2496 garyo 
18:20:07  <[GregNoel](GregNoel)>     oops, 2495 
18:19:57  <garyo>        see you later, Steven 
18:20:03  <garyo>        yes 
18:20:15  <sgk>  and 2496 too 
18:20:12  <[GregNoel](GregNoel)>     time to quit? 
18:20:26  <garyo>        sure, let's stop here. 
18:20:32  <sgk>  okay, i'm gone 
18:20:33  <garyo>        I'll spend some time tonight on 1.3 issues. 
18:20:37  <sgk>  thanks for a very productive time 
18:20:41  <[GregNoel](GregNoel)>     cul 
18:20:45  <garyo>        thx, sorry I was late. 
18:20:46  *      sgk has quit ("Leaving") 
18:20:59  <[GregNoel](GregNoel)>     it happens, and we made up for it. 
18:21:11  <garyo>        & thanks Greg for all the behind-the-scenes work. 
18:21:36  <[GregNoel](GregNoel)>     you're welcome 
18:21:19  <[GregNoel](GregNoel)>     what was the final on 2496? 
18:21:26  <garyo>        mine 
18:21:32  <[GregNoel](GregNoel)>     ok. 
18:21:59  <garyo>        see you on the mailing list... :-) 
18:22:09  <[GregNoel](GregNoel)>     Ah, good timing for me; dinner just announced. 
18:22:01  <garyo>        bye for now 
18:22:13  <[GregNoel](GregNoel)>     cul 
18:22:08  *      garyo (n=[garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com](mailto:garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)) has left #scons 
18:24:04  *      You have been marked as being away 

Updated