Please note:The SCons wiki is in read-only mode due to ongoing spam/DoS issues. Also, new account creation is currently disabled. We are looking into alternative wiki hosts.
   1 16:50:54 *	Jason_at_Intel (~chatzilla@12.18.240.224) has joined #SCONS
   2 16:52:29 *	GregNoel is no longer marked as being away
   3 16:53:51 <Jason_at_Intel>	hello
   4 16:53:59 *	Garyo (~chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS
   5 16:54:12 <Jason_at_Intel>	Hi Gary
   6 16:54:21 <Garyo>	Hi Jason.
   7 17:02:17 <Garyo>	Hi Greg -- feel free.  I'm starting to get some SCons time in the next few months (I hope!)
   8 17:05:34 *	bdbaddog (~bdeegan@adsl-71-131-3-198.dsl.sntc01.pacbell.net) has joined #SCONS
   9 17:06:03 <Garyo>	Hi Bill!
  10 17:06:19 <bdbaddog>	hey
  11 17:06:39 <Garyo>	Thanks (again) for pushing out the checkpoint; this one is looking good.
  12 17:06:45 <GregNoel>	We're short Steven, but he commented in the spreadsheet; should we begin?
  13 17:06:52 <bdbaddog>	sure.
  14 17:06:57 <Garyo>	I think so too.
  15 17:07:14 <GregNoel>	2517
  16 17:07:36 <GregNoel>	Steven says give it to him, but I don't like it as research.
  17 17:08:02 <Garyo>	I think it's his choice, is that OK?
  18 17:08:36 <GregNoel>	Yeah, but I don't think he should work on it until post-2.0.
  19 17:09:06 <Garyo>	Ah, I see.  Spend his cycles getting the python 2.4 stuff in now instead?
  20 17:09:16 <GregNoel>	Yes.
  21 17:09:43 <Garyo>	That makes a lot of sense.  I'm worried the 1.3 -> 2.0 transition will take a long time.
  22 17:10:23 <GregNoel>	It better not; I'll be flat on my back if it does...
  23 17:09:42 <GregNoel>	What's the priority on 2550?  I didn't look.
  24 17:10:02 <Garyo>	2550=p3
  25 17:10:29 <GregNoel>	What's the milestone?
  26 17:10:45 <Garyo>	research
  27 17:11:03 <GregNoel>	Ouch.  OK, make them the same: research p3.
  28 17:11:27 <Garyo>	OK, or move both to 2.1 p3 if you like.
  29 17:11:45 <GregNoel>	I'll put in a note that this "research" is less priority than 2.0.
  30 17:11:53 <Garyo>	+1
  31 17:11:58 <GregNoel>	done
  32 17:12:02 <GregNoel>	1549
  33 17:12:09 <GregNoel>	oops, 2549
  34 17:12:48 <Garyo>	Here's where I say I am really happy Russel is taking the lead in putting tools in a DVCS.
  35 17:13:24 <GregNoel>	I agree.  I'm not sure I agree with his choice of DVCS, but any choice is better than none.
  36 17:13:34 <bdbaddog>	he's certainly bringing the email volume up..
  37 17:14:09 <Garyo>	So... can we make a new category of issues for external tools, and this can be one?
  38 17:14:27 <Garyo>	(I know it's half here & half there, so it's confusing.)
  39 17:14:28 <GregNoel>	Hmmm...  Possible.  Needs discussion.
  40 17:14:47 <GregNoel>	Not something to settle today, surely.
  41 17:14:59 <Jason_at_Intel>	+1
  42 17:15:01 <Garyo>	Agreed.  Just let Russel work on it for now.
  43 17:15:31 <GregNoel>	so 2549, 3.x, what priority?
  44 17:15:42 <Garyo>	So 3.x p4?
  45 17:15:53 <GregNoel>	Hmmm...
  46 17:16:15 <GregNoel>	I think I'd like it to resurface sooner than that.
  47 17:16:44 <Garyo>	I'm hoping we'll decide some day to take the D tool out of SCons entirely instead.
  48 17:16:53 <GregNoel>	Yeah, along with Java.
  49 17:17:02 <Garyo>	... and latex, and ...
  50 17:17:03 <Jason_at_Intel>	why?
  51 17:17:16 <GregNoel>	Make them all user-supported.
  52 17:17:16 <Garyo>	Because they can be developed and released asynchronously.
  53 17:17:17 <Jason_at_Intel>	oh make them add on
  54 17:17:47 <Jason_at_Intel>	in that case most of the tools can go that route
  55 17:18:19 <Garyo>	Jason: agreed.  But we have to balance that with the python "batteries included" philosophy.
  56 17:17:55 <Garyo>	(We could do a linux distro thing and include the latest blessed version... or not even that.  All up for discussion.)
  57 17:18:08 <GregNoel>	Yeah, 2549 3.x p4; reassign it when we have a separate user-supported flow.
  58 17:18:27 <Garyo>	Greg: +1
  59 17:18:32 <GregNoel>	done
  60 17:18:39 <GregNoel>	2566
  61 17:18:42 <Garyo>	2566 is already closed.
  62 17:18:52 <Garyo>	can't repro.
  63 17:19:03 <GregNoel>	WORKSFORME?
  64 17:19:34 <Garyo>	I said INVALID because he couldn't repro it either :-)
  65 17:19:58 <GregNoel>	worksforme, then. {;-}
  66 17:19:27 <GregNoel>	In any event, 2571
  67 17:20:13 <Jason_at_Intel>	2571? is this calling Scons under the covers still?
  68 17:20:29 <Garyo>	Jason: sure.
  69 17:20:15 <Garyo>	2571: tell OP good job, give some direction on compat, then integrate for 2.1?
  70 17:20:28 <GregNoel>	I'll go along.
  71 17:20:38 <GregNoel>	Who?  Gary?
  72 17:20:47 <Garyo>	I'll take it.
  73 17:21:17 <GregNoel>	Obviously needs  some test cases, but I like the scheduling.
  74 17:21:04 <Garyo>	(Not that I care about MSVS, but I do care about new contributors.)
  75 17:21:27 <Jason_at_Intel>	it start small then grows
  76 17:21:41 <GregNoel>	2.1 p3 Garyo, done
  77 17:22:09 <GregNoel>	2572, defer?
  78 17:22:29 <Garyo>	sure
  79 17:22:33 <Jason_at_Intel>	+1
  80 17:22:37 <bdbaddog>	+1
  81 17:22:47 <GregNoel>	done
  82 17:22:56 <GregNoel>	2573
  83 17:22:59 <Garyo>	2573: what is ".sx"?
  84 17:23:10 <Jason_at_Intel>	:-) was just going to ask that
  85 17:23:15 <bdbaddog>	some .net file?
  86 17:23:22 <GregNoel>	Man page says "preprocessed assembler"
  87 17:23:33 <GregNoel>	(It's in the spreadsheet comments.)
  88 17:23:36 <Garyo>	for what OS?
  89 17:23:44 <GregNoel>	Any?
  90 17:23:56 <Garyo>	what man page did you find it in?
  91 17:24:24 <GregNoel>	SCons man page.
  92 17:24:48 <GregNoel>	We currently preprocess those files, but apparently don't scan them for dependencies.
  93 17:24:56 <Garyo>	Oh?!  Wow, that's a surprise!
  94 17:25:05 <GregNoel>	It was to me, too.
  95 17:25:09 <Garyo>	OK, I guess you guys are right, add it to the list.
  96 17:25:37 <Garyo>	I'll do that too.  The work part is trivial.
  97 17:25:49 <Garyo>	2.1 p4 garyo +easy
  98 17:25:51 <GregNoel>	OK, done, but watch for side-effects: it may try to compile the file.
  99 17:26:07 <Garyo>	ok, put a note in if you don't mind...
 100 17:26:17 <GregNoel>	Wilco
 101 17:26:33 <GregNoel>	2574
 102 17:27:02 <GregNoel>	Another trivial change, but would work better post-2.0.
 103 17:27:16 <Garyo>	Agreed.  Post 2.0.
 104 17:27:33 <Garyo>	2.1 p2, who?
 105 17:28:08 <GregNoel>	Not seeing any volunteers...
 106 17:28:19 <GregNoel>	I can't take it; I'll be recovering.
 107 17:28:36 <Garyo>	Understood.  Assign it to me then, I'll delegate if needed.
 108 17:28:41 <GregNoel>	done
 109 17:28:48 <GregNoel>	2575
 110 17:28:59 <Jason_at_Intel>	2575 ... it would be better if we had a src_dir which could be used as a root, to allow -j based builds to work
 111 17:29:22 <Garyo>	That's an excellent idea.
 112 17:29:39 <Garyo>	Jason, can you propose that to the OP and ask for a new patch?
 113 17:29:50 <Jason_at_Intel>	(zipfile in Parts :-) .. not as good as raw zip however in some cases)
 114 17:30:09 <Jason_at_Intel>	sure.. main problem is the call more than once issue
 115 17:30:29 <Jason_at_Intel>	the builders think the output is more than one environment
 116 17:30:16 <GregNoel>	Um, it would have to work for all builders, not just this one.
 117 17:30:32 <Garyo>	Would it, Greg?  Couldn't it just be an env override?
 118 17:31:07 <GregNoel>	No, I don't think so.  Think of LaTeX, for example, which wants to run in the build directory.
 119 17:31:10 <Garyo>	And Jason, if it's an env var, shouldn't it be constant for all calls anyway?  (I think I see your point though, still causes a warning)
 120 17:31:24 <Jason_at_Intel>	that is why i made a zipfile() and not override zip() as this changes behavior of calling more than once
 121 17:31:46 <Garyo>	Greg: I don't think tar/zip need to *run* in any particular dir, they just need a reference point.
 122 17:32:39 <Garyo>	OK, maybe this is more complicated than it seems at first.
 123 17:32:40 <Jason_at_Intel>	however for 2575 his patch will work.. it will just break -j builds
 124 17:33:00 <Garyo>	Jason: that worries me.
 125 17:33:07 <GregNoel>	Actually, tar/zip can have multiple changes of directory in them; that's why I like the solution in 1890.
 126 17:33:31 *	Garyo looks at 1890
 127 17:34:15 <Jason_at_Intel>	ie use the tarfile module?
 128 17:34:23 <Garyo>	I see, use tarfile instead of calling tar.  I totally agree.
 129 17:34:34 <GregNoel>	Garyo, basically, each entry is a duple of (name-in-archive, File-node).
 130 17:34:48 <Jason_at_Intel>	I have an impl in Parts for this
 131 17:34:59 <Jason_at_Intel>	but again i don't have it support more than one call
 132 17:35:15 <Garyo>	It's a call-once-with-all-sources builder?
 133 17:35:28 <Jason_at_Intel>	yep
 134 17:35:44 <Jason_at_Intel>	again the src_dir overide upsets teh builders
 135 17:35:54 <Jason_at_Intel>	spits out warnings or errors
 136 17:35:58 <Garyo>	Not ideal, of course, but probably best we can do given builder limitations
 137 17:36:08 <GregNoel>	I have a functional prototype for 1890, but I've been waiting for post-2.0 to implement it.
 138 17:36:29 <Garyo>	And calling with a single src dir is probably 90% of all use cases anyway.
 139 17:37:11 <Jason_at_Intel>	can you look at http://parts.tigris.org/source/browse/*checkout*/parts/trunk/parts/parts/pieces/tar.py?revision=143&content-type=text%2Fplain
 140 17:37:13 <GregNoel>	Then why not base it off of chdir=?  It's the effect that counts, not the actual functioning.
 141 17:37:51 <Garyo>	because of breaking -j, right?
 142 17:38:10 <Jason_at_Intel>	I think the chdir in SCons means current dir change
 143 17:38:26 <Jason_at_Intel>	Scons needs a new idea to support the "root" area to use
 144 17:38:38 <Garyo>	OK, so for 2575: 2.1, p2, Jason and Greg to investigate Jason and Greg's work, and come up with a nice solution.
 145 17:38:40 <Jason_at_Intel>	src_dir is what i would propose
 146 17:39:04 <GregNoel>	I don't agree.
 147 17:39:26 <Garyo>	don't agree w/ src_dir, or don't agree w/ my assignment?
 148 17:39:27 <Jason_at_Intel>	to me .. not gary .. correct?
 149 17:39:58 <GregNoel>	don't agree with src_dir; again, the effect is the requirement, not the actuality.
 150 17:40:15 <Jason_at_Intel>	??
 151 17:40:38 <Garyo>	I think you're saying it should get chdir before SCons actually changes the dir, and just use that dir itself.
 152 17:40:52 <GregNoel>	Yes
 153 17:41:01 <Garyo>	Might require a little core patching but not impossible of course.
 154 17:41:15 <Jason_at_Intel>	that is fine.. then does this mean we will fix command to do the same
 155 17:41:21 <Garyo>	(like a "builder_wants_chdir" flag or something)
 156 17:41:35 <Jason_at_Intel>	will it out add a cd <dir> && to the command?
 157 17:42:15 <Garyo>	Jason: at least the infrastructure would be there to handle it that way if we wanted to.
 158 17:42:22 <GregNoel>	I'm not going to design on the fly; my suggestion was to reject this issue as invalid, since it's the same problem with all builders where you use chdir=.
 159 17:43:07 <GregNoel>	If we change that paradigm, we need to make it consistent.
 160 17:42:57 <Jason_at_Intel>	so back to the issue
 161 17:43:02 <Jason_at_Intel>	this is a patch
 162 17:43:11 <Jason_at_Intel>	that is invalid?
 163 17:43:13 <Garyo>	Let's not say it's invalid then, but we think there's a better method.
 164 17:43:24 <GregNoel>	Garyo, yes.
 165 17:43:51 <Jason_at_Intel>	i see... not sure what the better method you have in mind is
 166 17:44:08 <Garyo>	Leave the issue open for this particular builder, but note that it requires a little infrastructure work to expose chdir to the builder, then we can do it better.
 167 17:44:29 <Jason_at_Intel>	agree
 168 17:44:48 <Garyo>	Jason: a builder flag that would tell scons not to chdir, but pass the chdir arg as a kwd arg to the builder.  Or something like that.
 169 17:45:11 <GregNoel>	And you could have chdir= on each builder call.
 170 17:45:13 <Jason_at_Intel>	I guess... but you woudl always want it on.. never off
 171 17:45:20 <Garyo>	(Greg, is that basically your idea?)
 172 17:45:42 <GregNoel>	Still designing on the fly, but yes, I think so.
 173 17:45:44 <Garyo>	Jason: we can't turn it on for all builders because most of them don't understand it.
 174 17:45:59 <loonycyborg>	chdir is clearly hack in this case.
 175 17:46:26 <GregNoel>	Hi, Sergey; glad you could join us.  Do you think users would understand a distinction there?
 176 17:46:29 <loonycyborg>	There should be more flexible ways to specify paths that'll be stored in the archive,
 177 17:46:32 <Garyo>	loonycyborg: yes, we'd be "repurposing it" a bit.
 178 17:46:51 <Jason_at_Intel>	Sure.. I will wait to see what greg proposes.. however from a generic pragma.. chdir is designed in SCons to mean something, changing its logic seem bad, better to add a new "verb" to say what we want clearly
 179 17:47:34 <Garyo>	OK, so given that let's not design it here but just say in the ticket that it needs thought and some internal changes before we can do it right.
 180 17:47:45 <Jason_at_Intel>	agree
 181 17:48:02 <GregNoel>	OK, then what should we do with the ticket?
 182 17:48:37 <GregNoel>	I'll suggest deferring to the mailing list.
 183 17:48:43 <Garyo>	How about this: mark it 2.1 p2, but with a note to say revisit at that time and discuss.
 184 17:48:58 <Jason_at_Intel>	+1
 185 17:49:00 <GregNoel>	Yes
 186 17:49:08 <bdbaddog>	+1
 187 17:49:08 <Garyo>	(rather than have a complete implementation by that time)
 188 17:49:16 <GregNoel>	done
 189 17:49:18 <Garyo>	good, consensus!
 190 17:53:13 <loonycyborg>	Zip builder should store paths relative to shortest common path of sources by default IMO..
 191 17:53:35 <GregNoel>	And that's what I'd like to do with 1890.
 192 17:54:24 <GregNoel>	Always put in a duple with relative path and File node.
 193 17:53:49 <Garyo>	loonycyborg: put a note in those 2 tickets if you want.
 194 17:54:54 <Garyo>	I like explicit rather than implicit in general though, even if it's a little more typing.
 195 17:55:19 <GregNoel>	Garyo, yes.
 196 17:55:02 <Jason_at_Intel>	lonnycyborg.. I agree.. that is what I have in Parts as well
 197 17:55:04 <GregNoel>	Remember, relative path is expensive to calculate; should try to avoid it when possible.
 198 17:55:06 <Garyo>	...but we're trying to design it here.
 199 17:55:15 <Garyo>	let's not.
 200 17:49:37 <GregNoel>	2576
 201 17:50:00 <Garyo>	2576 looks like good potential for Russel to feed Steven things.
 202 17:50:28 <GregNoel>	Yes.
 203 17:51:13 <GregNoel>	I wonder if "anytime" would work for this, as they work out the interaction details.
 204 17:51:19 <Garyo>	2.x p3, Steven to own, and work w/ Russel?
 205 17:51:57 <Garyo>	(Or vice versa, Russel to own, delegate work to Steven?)
 206 17:52:08 <GregNoel>	I could buy 2.x p3, but I'd like to see a procedure worked out first.
 207 17:52:37 <GregNoel>	Russel to own during design, Steven to own during implementation?
 208 17:52:57 <Garyo>	OK then, let's ask Steven to work something like that out & revisit next meeting. OK?
 209 17:53:12 <GregNoel>	yes, I like that.
 210 17:53:18 <bdbaddog>	+1
 211 17:53:25 <Jason_at_Intel>	+1
 212 17:55:40 <GregNoel>	We seem to have covered the issues; I have one thing on schedule.
 213 17:56:21 <GregNoel>	I can't make the next meeting; should we think about one week or three weeks for the next party?
 214 17:55:21 <Jason_at_Intel>	so 1.3
 215 17:55:37 <Garyo>	Yes, 1.3.  I'm in favor of moving aggressively to release.
 216 17:56:13 <Garyo>	I have 2 issues to test and one which won't get into 1.3.
 217 17:56:45 *	loonycyborg really hopes that 2443 will be fixed in 1.3
 218 17:57:30 <Garyo>	:-( that's my one I thought wouldn't make it.  I'll make an effort for it.
 219 17:57:32 <GregNoel>	loonycyborg, if the current checkpoint is the final candidate, that won't happen.  Sorry.
 220 17:57:34 <bdbaddog>	seems unlikely. we're on the runway to 1.3 launch..
 221 17:58:01 <Garyo>	They're right, things I've looked at would destabilize.
 222 17:59:00 <Jason_at_Intel>	hmm  2443 works for me.
 223 17:58:23 <Garyo>	Let's get 1.3 and 2.0 out asap.
 224 17:58:39 <Garyo>	Then we can get back on a shorter & less constricted release cycle.
 225 17:58:57 <bdbaddog>	yaha
 226 17:59:11 <bdbaddog>	so 1.3 this weekend then?
 227 17:59:14 <GregNoel>	Can you get back to all the people who've had problems with vs_revamp and get them to try the checkpoint?
 228 17:59:33 <GregNoel>	If so, this weekend sounds fine to me.
 229 17:59:35 <Garyo>	Greg: yes, those are the 2 issues on my test list.
 230 17:59:57 <Garyo>	Bill: I'll try to review the release docs soon.  I'm happy to help wordsmith.
 231 18:00:56 <Garyo>	Is the release process pretty much as documented on the wiki now?
 232 18:02:09 <Garyo>	I'll be skiing this wkend, but around this week and next.
 233 18:02:12 <bdbaddog>	yes. though I might move a few steps around to streamline
 234 18:02:36 <Garyo>	OK, let me help; you've done a lot.
 235 18:03:00 <Garyo>	Do you think this wkend is possible?
 236 18:03:36 <bdbaddog>	to get feedback on the couple of issues msvs/vc/sdk which have been reported?
 237 18:04:13 <Garyo>	I think that should be possible.
 238 18:04:21 <GregNoel>	If you can get it done this weekend, I can start on 2.0 on Tuesday after I get back from Cabo.
 239 18:05:14 <Garyo>	Bill: I have the "missing VCs on empty SConstruct" one and "wrong bat file for VS2005" and I think both are now fixed.
 240 18:05:31 <bdbaddog>	there's two more.
 241 18:05:55 <bdbaddog>	this one: http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=2455554
 242 18:06:23 <Garyo>	Oh right, missing gdi32.lib.
 243 18:06:50 <bdbaddog>	and one with vc2010rc + a bunch of other isntalled vc's and it not picking  up the requested one.
 244 18:08:00 <bdbaddog>	I had a win7 license from when they gave out the free trials, but it's expired.
 245 18:07:51 <Garyo>	I think we have to draw the line somewhere or we'll never get it out.
 246 18:08:08 <bdbaddog>	yeah. I think so too.
 247 18:08:11 <bdbaddog>	back in a minute..
 248 18:08:12 <Garyo>	I have a win7 machine now.
 249 18:08:57 <Garyo>	The missing gdi32.lib might be simple, or we might be able to give him a simple workaround (he hardcoded a bunch of stuff in his old version, as most people did.)
 250 18:09:22 <Jason_at_Intel>	what is win7 needed for?
 251 18:09:54 <Garyo>	I think bdbaddog's 2nd issue, from the ML.
 252 18:09:58 <bdbaddog>	I just needed a 64 bit some flavor of windows to build up a vm to try and reproduce some of the reported issues.
 253 18:10:24 <Jason_at_Intel>	ahh
 254 18:10:49 <Jason_at_Intel>	was masm tool fixed to use ml64?
 255 18:11:04 <Garyo>	I don't remember.
 256 18:11:10 <bdbaddog>	donno.
 257 18:11:13 <Garyo>	Try it :-)
 258 18:11:22 <bdbaddog>	or check the bug to see if it's marked fixed.
 259 18:11:40 <Jason_at_Intel>	I think it still uses ml
 260 18:13:15 <Jason_at_Intel>	yep.. still broken
 261 18:11:51 <Garyo>	So I say let's look at the missing gdi32 one, but with the vc2010 one let's say we are too close to 1.3 to change things now.
 262 18:12:27 <bdbaddog>	the gdi32 I think it's setting up right the first time,and the second time it's not. maybe default env and his initial Environmnet()
 263 18:12:49 <Garyo>	That's usually what that means.
 264 18:14:04 <bdbaddog>	I'm guessing somehow the sdk/vc logic combo is not quite right, but only in some corner cases.
 265 18:13:51 <Garyo>	I really want to get the site_scons dirs in too, so the sooner we can get moving on 2.0 the better.
 266 18:13:26 <Garyo>	Sorry.  2.1.
 267 18:14:14 <bdbaddog>	I hear u. I want 1.3 done.
 268 18:14:19 <bdbaddog>	I'm tired of py 1.5.2
 269 18:14:19 <Jason_at_Intel>	on that i have mirrored this in Parts (with part-site)
 270 18:15:32 <Garyo>	So let's forge ahead, hoping to get 1.3 out early next week? (Sounds like not all the test results will be in til then.)
 271 18:15:34 <Jason_at_Intel>	so go with what we have with vs_revamp and patch in 2.0?
 272 18:15:57 <Garyo>	Jason: yes, or 2.1 actually.  2.0 = 1.3 with python floor update.
 273 18:15:58 <bdbaddog>	what's in vs_revamp? it's all on trunk
 274 18:16:11 <Garyo>	yes, trunk.
 275 18:16:25 <Jason_at_Intel>	sorry mean the "feature" not branch
 276 18:16:51 <Jason_at_Intel>	so this mean 2.0 will be soon after 1.3?
 277 18:17:06 <GregNoel>	I'll have three weeks,
 278 18:17:42 <GregNoel>	which won't be enough, but I'm hoping I'll be far enough that someone else can finish getting out the checkpoints and release itself.
 279 18:17:06 <Garyo>	hopefully!
 280 18:17:07 <bdbaddog>	yes. that's the plan.
 281 18:17:19 <Jason_at_Intel>	great!
 282 18:17:22 <bdbaddog>	no features in 2.0, just remove 1.5.2->2.3 code.
 283 18:17:24 <bdbaddog>	right?
 284 18:17:32 <Jason_at_Intel>	2.4?
 285 18:17:34 <Garyo>	agreed.
 286 18:17:49 <Jason_at_Intel>	thought 2.3 was broken on some platforms
 287 18:18:00 <bdbaddog>	we're dropping 2.3
 288 18:18:04 <bdbaddog>	and below.
 289 18:18:09 <Garyo>	2.4 is the new floor.
 290 18:18:13 <bdbaddog>	yes.
 291 18:18:17 <Jason_at_Intel>	:-)
 292 18:19:04 <Garyo>	ok, let's do it!
 293 18:19:13 <bdbaddog>	k.
 294 18:19:24 <GregNoel>	OK, is that it for 1.3?  When should the next party be?  One week, two weeks, or three weeks?  I can't be there if it's two weeks.
 295 18:19:48 <bdbaddog>	should we make the call next tues on 1.3?
 296 18:20:00 <Garyo>	+1
 297 18:20:00 <Jason_at_Intel>	+1
 298 18:20:07 <bdbaddog>	or we can handle on release mailing list if things are resolved sooner.
 299 18:20:23 <Garyo>	fine.
 300 18:21:01 <GregNoel>	One week, then?
 301 18:21:16 <Garyo>	good with me.
 302 18:21:34 <bdbaddog>	k. virtually c u all then.
 303 18:21:44 <Jason_at_Intel>	same!
 304 18:21:49 <GregNoel>	OK, see you all in one week.
 305 18:21:54 <Garyo>	bye 4 now.
 306 18:22:00 <Jason_at_Intel>	bye
 307 18:22:04 <GregNoel>	Got to go, dinner is calling.
 308 18:22:12 <bdbaddog>	l8r
 309 18:22:22 <GregNoel>	G'day all.
 310 18:22:29 *	GregNoel has been marked as being away
 311 18:23:38 *	bdbaddog (~bdeegan@adsl-71-131-3-198.dsl.sntc01.pacbell.net) has left #SCONS
 312 18:32:20 *	Jason_at_Intel has quit (Quit: ChatZilla 0.9.86 [Firefox 3.5.3/20090824101458])
 313 18:38:08 *	loonycyborg has quit (Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz)
 314 18:45:54 *	Garyo has quit (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100202165920])
 315 

BugParty/IrcLog2010-03-09 (last edited 2010-03-10 11:27:48 by ip68-7-77-81)