Please note:The SCons wiki is now restored from the attack in March 2013. All old passwords have been invalidated. Please reset your password if you have an account. If you note missing pages, please report them to webmaster@scons.org. Also, new account creation is currently disabled due to an ongoing spam flood (2013/08/27).
   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)