1 16:02:51 *	sgk (n=stevenkn@nat/google/x-ncfwmskxkmsbaijr) has joined #scons
   2 17:00:59 <sgk>	anyone else here yet for bug party?
   3 17:01:48 *	You are no longer marked as being away
   4 17:02:05 <GregNoel>	Hi, Steven, just got here; give me a minute to set up.
   5 17:04:39 <sgk>	np, i'm still getting set up myself
   6 17:05:57 *	sgk really needs to install colloquy
   7 17:06:41 <GregNoel>	What's that?  Some flavor of wave?
   8 17:07:18 <sgk>	better mac irc client than x-chat aqua
   9 17:07:34 <sgk>	i've installed it on my desktop mac at work, but not my macbook
  10 17:07:43 <GregNoel>	Why is it better?
  11 17:12:27 <GregNoel>	Where is everybody?
  12 17:13:07 <sgk>	yeah, where is everyone?  i know bill's on a plane, but i thought for sure garyo would be here
  13 17:13:25 <GregNoel>	ditto
  14 17:13:29 *	sgk sighs
  15 17:14:56 <sgk>	then i say we just start assigning all the issues to garyo+bdbaddog+Jason_at_intel in rotation
  16 17:15:07 <GregNoel>	worksforme
  17 17:18:26 <GregNoel>	We can talk a bit about QMTest if you want.  I have a couple of things I want to mention.
  18 17:19:43 <sgk>	sure
  19 17:19:48 <GregNoel>	About QMTest (and SCons testing in general):
  20 17:19:48 <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.
  21 17:19:48 <GregNoel>	I think unittest should be made a base class for the SConsTest hierarchy, making those functions available for integrated tests as well.
  22 17:19:48 <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.
  23 17:19:48 <GregNoel>	I think the tests should be timed, and the times reported.
  24 17:19:48 <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.
  25 17:19:48 <GregNoel>	I think there should be four types of test returns:
  26 17:19:48 <GregNoel>	-1- PASSED meaning that the test was run and everything succeeded.
  27 17:19:48 <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)
  28 17:19:48 <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)
  29 17:19:48 <GregNoel>	-4- FAILED meaning that the test was run and found some problem.
  30 17:19:48 <GregNoel>	The last two should be summarized (separately!) at the end of the run.
  31 17:19:48 <GregNoel>	(I've been practicing my typing speed; how'm I doing?)
  32 17:21:25 <sgk>	impressive!
  33 17:22:11 <sgk>	seems reasonable to me
  34 17:23:00 <GregNoel>	I suppose I should write it up in a design note in the wiki, now that I've written it once already.
  35 17:23:08 <sgk>	not a bad idea
  36 17:23:01 *	garyo (n=garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #scons
  37 17:23:08 <GregNoel>	Ah-HA!
  38 17:23:15 <garyo>	Hi guys
  39 17:23:23 <GregNoel>	A bit late, are we?
  40 17:23:30 <sgk>	i have to run to the shuttle, i'll be back on after it shows up in ~5 - 10 minutes
  41 17:23:34 *	sgk has quit ("This computer has gone to sleep")
  42 17:23:46 <GregNoel>	Good timing, I guess...
  43 17:23:54 <garyo>	sorry, too much kids stuff
  44 17:24:09 <garyo>	what'd I miss?
  45 17:24:12 <GregNoel>	Just some QMTest stuff.
  46 17:24:16 <GregNoel>	So, would you like to chat about QMTest while we're waiting for Steven to get back?
  47 17:24:21 <garyo>	ok
  48 17:24:25 <GregNoel>	About QMTest (and SCons testing in general):
  49 17:24:25 <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.
  50 17:24:25 <GregNoel>	I think unittest should be made a base class for the SConsTest hierarchy, making those functions available for integrated tests as well.
  51 17:24:25 <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.
  52 17:24:25 <GregNoel>	I think the tests should be timed, and the times reported.
  53 17:24:25 <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.
  54 17:24:25 <GregNoel>	I think there should be four types of test returns:
  55 17:24:25 <GregNoel>	-1- PASSED meaning that the test was run and everything succeeded.
  56 17:24:25 <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)
  57 17:24:25 <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)
  58 17:24:25 <GregNoel>	-4- FAILED meaning that the test was run and found some problem.
  59 17:24:25 <GregNoel>	The last two should be summarized (separately!) at the end of the run.
  60 17:24:25 <GregNoel>	(I've been practicing my typing speed; how'm I doing?)
  61 17:25:04 <garyo>	:-)
  62 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.
  63 17:25:59 <GregNoel>	(fwk?)
  64 17:26:04 <garyo>	framework
  65 17:26:09 <GregNoel>	Ah.
  66 17:26:23 <GregNoel>	I agree.
  67 17:26:40 <garyo>	Probably most of what we use QMtest for is in the higher-level TestSCons etc. classes anyway.
  68 17:26:58 <GregNoel>	Yeah, I think so, too.
  69 17:26:45 <GregNoel>	QMTest has a lot going for it, but we use so little of it.
  70 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.
  71 17:27:39 <GregNoel>	One step at a time.
  72 17:27:49 <garyo>	(Like timing, timeouts, new & interesting reports, etc.)
  73 17:28:29 <GregNoel>	The timeout is primarily for KeyboardInterrupt which still stalls now and again.
  74 17:28:24 <garyo>	So we just make --noqmtest the default, right?  That's the 1st step?
  75 17:28:48 <GregNoel>	I think so; it gets rid of a diagnostic.
  76 17:29:03 <garyo>	yes, I've seen it.  That kind of thing will be easier with subprocess support I think (?)
  77 17:29:26 <garyo>	So this would be a post-1.3 thing?
  78 17:29:54 <GregNoel>	Post 1.3, yes.  Newer Python constructs will help.
  79 17:30:51 *	sgk (n=stevenkn@67.218.106.196) has joined #scons
  80 17:30:57 <GregNoel>	I should write up a wiki page, now that I've written it once already.  Sigh, yet more words cast into the blue.
  81 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.)
  82 17:31:02 <sgk>	back.  what'd i miss?
  83 17:31:15 <GregNoel>	Continuing on QMTest.
  84 17:31:17 <garyo>	Hi, Greg just gave me his =noqmtest spiel
  85 17:31:22 <garyo>	:-)
  86 17:31:22 <sgk>	cool
  87 17:31:28 <garyo>	I basically agree
  88 17:31:38 <sgk>	i basically agree too
  89 17:31:46 <garyo>	just take it in small steps
  90 17:31:32 <sgk>	couple comments / questions
  91 17:31:53 <sgk>	clarification:  perceived advantage of unittest as base?
  92 17:31:59 <sgk>	i have mixed emotions about unittest
  93 17:32:16 <garyo>	Our QA person is using it here; I can ask her what she thinks of it.
  94 17:32:30 <garyo>	I think we do want *some* framework underneath.
  95 17:32:48 <GregNoel>	It has some useful functions, some duplicated in the TestScons stack; harmless at worst if we're keeping it as a basis for unit tests.
  96 17:33:03 <sgk>	my main hesitation is that our system tests aren't unit tests in the classic sense
  97 17:33:20 <garyo>	Does that matter?
  98 17:33:21 <sgk>	concerned that shoehorning them into an unsuitable framework may mislead people or have other drawbacks
  99 17:33:26 <GregNoel>	The system tests, no, but it doesn't matter.
 100 17:33:28 <sgk>	not sure if it does or not
 101 17:33:32 <GregNoel>	jinx
 102 17:33:58 <garyo>	Is there an alternative fwk?
 103 17:34:13 <sgk>	homebrew, which is one of the reasons unittest is attractive
 104 17:34:38 <garyo>	Right, let's not reinvent the wheel.
 105 17:34:41 <sgk>	but what does the underlying framework buy us over homebrew?
 106 17:35:31 <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.
 107 17:34:59 <garyo>	A long time ago I remember looking at 'nose' which did some more auto-discovery.
 108 17:35:03 <garyo>	(compared to unittest)
 109 17:36:12 <garyo>	http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy has a big list.
 110 17:36:25 <GregNoel>	Anyway, I'll write it up in my copious spare time.
 111 17:36:36 <sgk>	well, i've already done some adaptation of TestCmd + TestCommon to gtest (google's flavor of unittest)
 112 17:37:06 <sgk>	so it wouldn't be too bad to do unittest itself
 113 17:36:48 <garyo>	what does it buy us?  IMHO, reporting is big, plus lots of assertions, exception handling, etc.
 114 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
 115 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
 116 17:38:31 <GregNoel>	Not to be a wet blanket, but we should triage some bugs.
 117 17:38:53 <sgk>	(garyo, good link re: test taxonomy)
 118 17:39:10 <GregNoel>	ditto
 119 17:39:28 <GregNoel>	I've already bookmarked it.
 120 17:39:21 <sgk>	fair enough, let's table the test specifics and get to the bugs
 121 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.
 122 17:39:35 <garyo>	ok, I'm ready
 123 17:39:56 <GregNoel>	2446 reprise
 124 17:40:00 <garyo>	2446: remove that line?
 125 17:40:19 <GregNoel>	I think so.  It doesn't appear to be used.
 126 17:40:28 <garyo>	ok, done.  I'll do it, assign it to me.
 127 17:40:37 <GregNoel>	done; thanks
 128 17:41:09 <sgk>	concur, it looks unnecessary
 129 17:41:09 <GregNoel>	2485
 130 17:41:16 <garyo>	research garyo
 131 17:41:36 <GregNoel>	done
 132 17:41:55 <GregNoel>	2469 consensus
 133 17:41:59 <garyo>	yup
 134 17:42:09 <sgk>	agree
 135 17:42:19 <GregNoel>	2470
 136 17:43:16 <GregNoel>	Is it something that should be fixed?
 137 17:42:25 <garyo>	2470: I asked OP for more details, he didn't have a user-level failure associated with it.
 138 17:42:27 <sgk>	garyo already asked
 139 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.
 140 17:43:35 <GregNoel>	Dir('.')?
 141 17:43:02 <sgk>	no user failure => invalid, i think
 142 17:43:22 <GregNoel>	yes, invalid.
 143 17:44:02 <sgk>	he should be able to query a node directly for that
 144 17:44:14 <sgk>	oh, wait
 145 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.
 146 17:44:27 <sgk>	that's one of those issues where there's no "the" variant dir
 147 17:44:35 <sgk>	you could be building multiple variants
 148 17:44:59 <garyo>	Right, he wants to go the reverse direction (as it were).
 149 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.
 150 17:45:30 <garyo>	(whatever that is)
 151 17:45:43 <garyo>	adjust -> alter, sorry
 152 17:45:43 <GregNoel>	Best he can do is get the current variant dir, using Dir().
 153 17:45:57 <garyo>	I'll mention that to him.
 154 17:46:31 <sgk>	k, invalid, garyo follows up with Dir('.")
 155 17:46:36 <GregNoel>	Since Gary's already on it, let him run with it and report back next time?
 156 17:46:45 <garyo>	well, ok.
 157 17:46:54 <GregNoel>	done
 158 17:47:23 <GregNoel>	2471
 159 17:47:59 <GregNoel>	It seems like future is too far out; I'd like it sooner.
 160 17:48:36 <GregNoel>	Searching also needs a magic token for "dir of source file"
 161 17:47:36 <sgk>	is it real or theoretical?
 162 17:47:43 <garyo>	It's real.
 163 17:47:55 <garyo>	<> never searches the current dir.
 164 17:47:58 <sgk>	which compiler(s)?
 165 17:48:05 <garyo>	gcc, msvc.
 166 17:48:32 <sgk>	?  if <> doesn't do that it's a regression
 167 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.
 168 17:48:42 <sgk>	oh
 169 17:49:17 <garyo>	In the limit it's quite complicated though (and compiler-specific).
 170 17:50:01 <GregNoel>	It's well into undefined territory in the C/C++ spec, but the convention seems common.
 171 17:49:04 <sgk>	that sounds like an outright bug in the behavior then
 172 17:49:27 <sgk>	that can just be fixed in the current code
 173 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
 174 17:50:31 <sgk>	so perhaps change scons' <> search in the current code for the short term
 175 17:50:43 <garyo>	I'd be happy w/ that.
 176 17:50:55 <sgk>	and a future to invent a CPPPATH replacement that allows separate "" vs. <> configuration?
 177 17:51:00 <garyo>	(It's not perfect but better than today)
 178 17:51:07 <GregNoel>	If we can do that short term, pushing the general case to future is fine with me.
 179 17:51:44 <garyo>	ok, steven 2.x p?
 180 17:51:47 <GregNoel>	OK, what priority on the short case?
 181 17:51:56 <garyo>	p3?
 182 17:52:01 <GregNoel>	works
 183 17:52:20 <GregNoel>	What priority when it goes into the future?
 184 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
 185 17:53:05 <garyo>	I'd say p4 for the future because people won't usually even notice.
 186 17:53:08 <sgk>	maybe 2.0 p2 for the short term fix
 187 17:53:12 <sgk>	future p3 for the long term
 188 17:54:00 <GregNoel>	Agree w/ Steven
 189 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
 190 17:53:32 <GregNoel>	And note that '.' isn't right for the local search path; it's "directory of source file"
 191 17:54:14 <garyo>	Greg: I'm not sure gcc and msvc agree 100% there.
 192 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)
 193 17:55:55 <GregNoel>	Same thing; it's relative to the file that includes it.
 194 17:54:34 <GregNoel>	Oops, Steven said 2.0.  It should be 2.x.
 195 17:54:43 <sgk>	okay, 2.x
 196 17:54:49 <GregNoel>	2.x p2 then future p3
 197 17:54:55 <sgk>	done
 198 17:54:55 <garyo>	fine
 199 17:55:04 <GregNoel>	done
 200 17:55:23 <garyo>	2472 I already closed
 201 17:55:26 <GregNoel>	done
 202 17:55:31 <garyo>	& 2473
 203 17:55:37 <garyo>	hope you guys don't mind
 204 17:55:38 <GregNoel>	++
 205 17:55:40 <sgk>	garyo++
 206 17:56:07 <GregNoel>	2474
 207 17:56:17 <sgk>	research, who?
 208 17:56:37 <sgk>	sign up bdbaddog?
 209 17:56:40 <garyo>	don't know, not me
 210 17:56:42 <GregNoel>	I don't think research is right
 211 17:57:18 <garyo>	Well, we don't know what's going on...
 212 17:57:20 <GregNoel>	We know about the problem with directories; there's even a SEP about it.
 213 17:57:20 <sgk>	seems like it needs some characterization...  back to op?
 214 17:57:47 <garyo>	"back to op" to me is a lot like "research"
 215 17:58:50 <GregNoel>	Seeing no consensus, pass to next time.
 216 17:59:00 <garyo>	OK w/ me.
 217 17:59:01 <GregNoel>	2475
 218 17:59:14 <GregNoel>	consensus
 219 17:59:28 <GregNoel>	2476
 220 17:59:52 <sgk>	ok
 221 18:00:07 <garyo>	option 1 seems good to me.
 222 18:00:19 <GregNoel>	I disagree with second option; some values cannot be modified (platform, for one)
 223 18:00:26 <GregNoel>	For the others, maybe.
 224 18:00:37 <garyo>	all the more reason to take option 1 :-)
 225 18:01:30 <sgk>	okay, first option is fine with me
 226 18:01:14 <GregNoel>	OK, I'll include a commentary; 2.x p4 who?
 227 18:01:37 <garyo>	Greg, maybe you could do it?  Or Bill?
 228 18:01:48 <GregNoel>	Or for 2.x, not a strong motivation to assign an owner now.
 229 18:02:07 <garyo>	ok, esp. w/ +Easy
 230 18:02:16 <sgk>	agree
 231 18:02:35 <GregNoel>	done
 232 18:02:18 <GregNoel>	Actually, a lot of it should be subsumed by revamped configure.
 233 18:02:35 <garyo>	and/or toolchain
 234 18:02:41 <sgk>	right
 235 18:02:48 <GregNoel>	Er, yes, that's what I meant.
 236 18:03:01 <GregNoel>	Closely related in my mind.
 237 18:02:57 <garyo>	2477: 2.1 p2 bdbaddog
 238 18:03:08 <GregNoel>	done
 239 18:03:23 <sgk>	2478:   2.x p3 bdbaddog
 240 18:03:27 <GregNoel>	done
 241 18:03:53 <sgk>	2479:  ask OP if he'd like to contribute
 242 18:03:56 <garyo>	2479: invalid, unless OP wants to work on it
 243 18:04:06 <GregNoel>	How can it be invalid+symlink?
 244 18:04:17 <sgk>	?
 245 18:04:51 <garyo>	1: ask OP if he's interested.  If yes, then it's him +symlink.  Else, invalid & close.
 246 18:04:51 <GregNoel>	If it's invalid, it goes away.  If it's +symlink, it's assigned with the other symlink issues.
 247 18:05:00 <garyo>	jinx
 248 18:05:08 <GregNoel>	concur w/ garyo
 249 18:05:14 <sgk>	oh, i see
 250 18:05:36 <sgk>	done
 251 18:05:40 <GregNoel>	done
 252 18:05:44 <garyo>	2480: research bdbaddog
 253 18:05:52 <sgk>	go badbaddog!
 254 18:05:58 <GregNoel>	done
 255 18:05:57 <garyo>	2481: already fixed.
 256 18:06:28 <GregNoel>	2481 done
 257 18:06:38 <GregNoel>	2482
 258 18:07:09 <garyo>	how about mark as future, hope it goes away w/ sconf revamp?
 259 18:06:57 <sgk>	2482 is hairy; no obvious course of action; defer to next time?
 260 18:07:16 <sgk>	lame, I know, but i don't think time here on it is productive
 261 18:07:20 <GregNoel>	yeah, I'll look at it between now and then
 262 18:07:21 <garyo>	agreed.
 263 18:07:27 <sgk>	done
 264 18:07:33 <GregNoel>	2483
 265 18:07:46 <sgk>	2.x p3 bdbaddog
 266 18:08:04 <sgk>	w/note re: clarifying whether the behavior is specific
 267 18:08:11 <garyo>	sounds good.
 268 18:08:29 <GregNoel>	OK.  (There's really only one java compiler, short of what GNU is doing, and we don't support that yet.)
 269 18:08:48 <sgk>	?  there's sun, there's blackdown, there's gcj...
 270 18:09:31 <sgk>	anyway
 271 18:09:33 <garyo>	Not my world.  Let me know when any of them can process 33Mpixels in 16msec.
 272 18:09:37 <GregNoel>	gcj is GNU, I don't know what its command line is like; blackdown follows Sun as far as I know.
 273 18:09:51 <garyo>	ok, let's keep moving... 2484
 274 18:09:54 <sgk>	2484:  2.1 p2 bdbaddog
 275 18:10:03 <garyo>	good.
 276 18:10:22 <GregNoel>	done
 277 18:10:32 <garyo>	2486: Steven, can you take that one?
 278 18:10:45 <sgk>	okay
 279 18:10:57 <sgk>	still 2.x p2 ?
 280 18:11:10 <sgk>	sure
 281 18:11:16 <garyo>	Sure (or p3, your call)
 282 18:10:47 <GregNoel>	done
 283 18:11:27 *	sgk has about 5 minutes to the shuttle stop
 284 18:11:42 <GregNoel>	2487, wontfix
 285 18:11:43 <sgk>	2.x p3 stevenknight
 286 18:11:47 <garyo>	2487: let's mark invalid.  The filter idea we can take up later.
 287 18:11:48 <sgk>	done
 288 18:12:05 <GregNoel>	ok, invalid
 289 18:12:09 <sgk>	2488:  2.x p2 bdbaddog
 290 18:12:19 <garyo>	yep
 291 18:12:24 <GregNoel>	done
 292 18:12:42 <garyo>	2489: future or 2.x?  Maybe 3.x?
 293 18:12:59 <GregNoel>	I don't use it; no opinion
 294 18:13:09 <sgk>	3.x sounds about right
 295 18:13:15 <sgk>	2.x would be nice, but there's already enough there
 296 18:13:20 <GregNoel>	too much
 297 18:13:25 <garyo>	It would take me a while to refactor my code to use it too.  Agree w/ Steven re: 3.x.
 298 18:13:31 <GregNoel>	p?
 299 18:13:34 <garyo>	3
 300 18:13:37 <sgk>	p3
 301 18:13:39 <GregNoel>	done
 302 18:13:54 <garyo>	2490: I asked for a patch.  We'll see.
 303 18:14:01 <GregNoel>	defer to next time
 304 18:14:02 <sgk>	2490:  is it passible he just added a C# module somewhere?
 305 18:14:07 <sgk>	defer++
 306 18:14:21 <garyo>	steven: definitely possible.
 307 18:14:39 <sgk>	i may take a look for the module while waiting for tests to run
 308 18:14:39 <garyo>	2491: anytime p4 sounds fine.
 309 18:14:51 <sgk>	anytime p4
 310 18:15:02 <GregNoel>	done
 311 18:15:11 <GregNoel>	oops, er, who?
 312 18:15:41 <GregNoel>	anytime needs an owner
 313 18:15:09 <garyo>	sgk: or you could knock of a +Easy one... better way to spend the time perhaps?
 314 18:15:11 <garyo>	:-)
 315 18:15:40 <garyo>	Steven, I think only you understand the packaging stuff well enough I think.
 316 18:15:50 <sgk>	garyo:  feel free to prioritize my time that way...
 317 18:15:54 <GregNoel>	I sure don't
 318 18:16:03 <sgk>	okay, me
 319 18:16:14 <GregNoel>	done
 320 18:16:55 <garyo>	btw speaking of time & priorities you have been very productive recently -- good to see!
 321 18:16:49 <GregNoel>	2492, assign to rob?
 322 18:17:03 <sgk>	2492:  could be draconian and also mark it fixed with invitation to re-open if that's hasty
 323 18:17:19 <garyo>	2492: agree w/ steven
 324 18:17:36 <GregNoel>	yes, concur.  done
 325 18:17:55 <garyo>	2493 consensus
 326 18:17:58 <GregNoel>	done
 327 18:17:59 <sgk>	done
 328 18:18:14 <sgk>	2494 anytime +Easy
 329 18:18:24 <GregNoel>	then who?
 330 18:18:40 <sgk>	doesn't +Easy mean it doesn't need a who?
 331 18:18:41 <garyo>	if we need an owner for an anytime, then I'd say 2.x or 3.x instead.
 332 18:18:51 <sgk>	okay, 2.x
 333 18:19:04 <sgk>	anything to avoid the dread "who?" question... :-)
 334 18:19:12 <GregNoel>	Hmmm... you're right, we have some +Easy anytime
 335 18:19:13 <garyo>	sgk: I think that makes sense, anytime +Easy no owner is fine w/ me.
 336 18:19:26 <sgk>	okay, anytime
 337 18:19:25 <GregNoel>	done
 338 18:19:41 *	sgk has < 1 minute
 339 18:19:46 <garyo>	2495 is for me
 340 18:19:50 <sgk>	done
 341 18:19:55 <GregNoel>	2496 garyo
 342 18:20:07 <GregNoel>	oops, 2495
 343 18:19:57 <garyo>	see you later, Steven
 344 18:20:03 <garyo>	yes
 345 18:20:15 <sgk>	and 2496 too
 346 18:20:12 <GregNoel>	time to quit?
 347 18:20:26 <garyo>	sure, let's stop here.
 348 18:20:32 <sgk>	okay, i'm gone
 349 18:20:33 <garyo>	I'll spend some time tonight on 1.3 issues.
 350 18:20:37 <sgk>	thanks for a very productive time
 351 18:20:41 <GregNoel>	cul
 352 18:20:45 <garyo>	thx, sorry I was late.
 353 18:20:46 *	sgk has quit ("Leaving")
 354 18:20:59 <GregNoel>	it happens, and we made up for it.
 355 18:21:11 <garyo>	& thanks Greg for all the behind-the-scenes work.
 356 18:21:36 <GregNoel>	you're welcome
 357 18:21:19 <GregNoel>	what was the final on 2496?
 358 18:21:26 <garyo>	mine
 359 18:21:32 <GregNoel>	ok.
 360 18:21:59 <garyo>	see you on the mailing list... :-)
 361 18:22:09 <GregNoel>	Ah, good timing for me; dinner just announced.
 362 18:22:01 <garyo>	bye for now
 363 18:22:13 <GregNoel>	cul
 364 18:22:08 *	garyo (n=garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has left #scons
 365 18:24:04 *	You have been marked as being away
 366 

BugParty/IrcLog2009-12-01 (last edited 2009-12-09 23:24:36 by ip68-7-77-81)