-
-
Notifications
You must be signed in to change notification settings - Fork 310
IrcLog2009 12 01
William Deegan edited this page Jan 14, 2016
·
2 revisions
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