IrcLog2010 03 09

William Deegan edited this page Jan 14, 2016 · 2 revisions
16:50:54  *      Jason_at_Intel (~[chatzilla@](mailto:chatzilla@ has joined #SCONS 
16:52:29  *      [GregNoel](GregNoel) is no longer marked as being away 
16:53:51  <Jason_at_Intel>       hello 
16:53:59  *      Garyo (~[]( has joined #SCONS 
16:54:12  <Jason_at_Intel>       Hi Gary 
16:54:21  <Garyo>        Hi Jason. 
17:02:17  <Garyo>        Hi Greg -- feel free.  I'm starting to get some SCons time in the next few months (I hope!) 
17:05:34  *      bdbaddog (~[]( has joined #SCONS 
17:06:03  <Garyo>        Hi Bill! 
17:06:19  <bdbaddog>     hey 
17:06:39  <Garyo>        Thanks (again) for pushing out the checkpoint; this one is looking good. 
17:06:45  <[GregNoel](GregNoel)>     We're short Steven, but he commented in the spreadsheet; should we begin? 
17:06:52  <bdbaddog>     sure. 
17:06:57  <Garyo>        I think so too. 
17:07:14  <[GregNoel](GregNoel)>     2517 
17:07:36  <[GregNoel](GregNoel)>     Steven says give it to him, but I don't like it as research. 
17:08:02  <Garyo>        I think it's his choice, is that OK? 
17:08:36  <[GregNoel](GregNoel)>     Yeah, but I don't think he should work on it until post-2.0. 
17:09:06  <Garyo>        Ah, I see.  Spend his cycles getting the python 2.4 stuff in now instead? 
17:09:16  <[GregNoel](GregNoel)>     Yes. 
17:09:43  <Garyo>        That makes a lot of sense.  I'm worried the 1.3 -> 2.0 transition will take a long time. 
17:10:23  <[GregNoel](GregNoel)>     It better not; I'll be flat on my back if it does... 
17:09:42  <[GregNoel](GregNoel)>     What's the priority on 2550?  I didn't look. 
17:10:02  <Garyo>        2550=p3 
17:10:29  <[GregNoel](GregNoel)>     What's the milestone? 
17:10:45  <Garyo>        research 
17:11:03  <[GregNoel](GregNoel)>     Ouch.  OK, make them the same: research p3. 
17:11:27  <Garyo>        OK, or move both to 2.1 p3 if you like. 
17:11:45  <[GregNoel](GregNoel)>     I'll put in a note that this "research" is less priority than 2.0. 
17:11:53  <Garyo>        +1 
17:11:58  <[GregNoel](GregNoel)>     done 
17:12:02  <[GregNoel](GregNoel)>     1549 
17:12:09  <[GregNoel](GregNoel)>     oops, 2549 
17:12:48  <Garyo>        Here's where I say I am really happy Russel is taking the lead in putting tools in a DVCS. 
17:13:24  <[GregNoel](GregNoel)>     I agree.  I'm not sure I agree with his choice of DVCS, but any choice is better than none. 
17:13:34  <bdbaddog>     he's certainly bringing the email volume up.. 
17:14:09  <Garyo>        So... can we make a new category of issues for external tools, and this can be one? 
17:14:27  <Garyo>        (I know it's half here & half there, so it's confusing.) 
17:14:28  <[GregNoel](GregNoel)>     Hmmm...  Possible.  Needs discussion. 
17:14:47  <[GregNoel](GregNoel)>     Not something to settle today, surely. 
17:14:59  <Jason_at_Intel>       +1 
17:15:01  <Garyo>        Agreed.  Just let Russel work on it for now. 
17:15:31  <[GregNoel](GregNoel)>     so 2549, 3.x, what priority? 
17:15:42  <Garyo>        So 3.x p4? 
17:15:53  <[GregNoel](GregNoel)>     Hmmm... 
17:16:15  <[GregNoel](GregNoel)>     I think I'd like it to resurface sooner than that. 
17:16:44  <Garyo>        I'm hoping we'll decide some day to take the D tool out of SCons entirely instead. 
17:16:53  <[GregNoel](GregNoel)>     Yeah, along with Java. 
17:17:02  <Garyo>        ... and latex, and ... 
17:17:03  <Jason_at_Intel>       why? 
17:17:16  <[GregNoel](GregNoel)>     Make them all user-supported. 
17:17:16  <Garyo>        Because they can be developed and released asynchronously. 
17:17:17  <Jason_at_Intel>       oh make them add on 
17:17:47  <Jason_at_Intel>       in that case most of the tools can go that route 
17:18:19  <Garyo>        Jason: agreed.  But we have to balance that with the python "batteries included" philosophy. 
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.) 
17:18:08  <[GregNoel](GregNoel)>     Yeah, 2549 3.x p4; reassign it when we have a separate user-supported flow. 
17:18:27  <Garyo>        Greg: +1 
17:18:32  <[GregNoel](GregNoel)>     done 
17:18:39  <[GregNoel](GregNoel)>     2566 
17:18:42  <Garyo>        2566 is already closed. 
17:18:52  <Garyo>        can't repro. 
17:19:03  <[GregNoel](GregNoel)>     WORKSFORME? 
17:19:34  <Garyo>        I said INVALID because he couldn't repro it either :-) 
17:19:58  <[GregNoel](GregNoel)>     worksforme, then. {;-} 
17:19:27  <[GregNoel](GregNoel)>     In any event, 2571 
17:20:13  <Jason_at_Intel>       2571? is this calling Scons under the covers still? 
17:20:29  <Garyo>        Jason: sure. 
17:20:15  <Garyo>        2571: tell OP good job, give some direction on compat, then integrate for 2.1? 
17:20:28  <[GregNoel](GregNoel)>     I'll go along. 
17:20:38  <[GregNoel](GregNoel)>     Who?  Gary? 
17:20:47  <Garyo>        I'll take it. 
17:21:17  <[GregNoel](GregNoel)>     Obviously needs  some test cases, but I like the scheduling. 
17:21:04  <Garyo>        (Not that I care about MSVS, but I do care about new contributors.) 
17:21:27  <Jason_at_Intel>       it start small then grows 
17:21:41  <[GregNoel](GregNoel)>     2.1 p3 Garyo, done 
17:22:09  <[GregNoel](GregNoel)>     2572, defer? 
17:22:29  <Garyo>        sure 
17:22:33  <Jason_at_Intel>       +1 
17:22:37  <bdbaddog>     +1 
17:22:47  <[GregNoel](GregNoel)>     done 
17:22:56  <[GregNoel](GregNoel)>     2573 
17:22:59  <Garyo>        2573: what is ".sx"? 
17:23:10  <Jason_at_Intel>       :-) was just going to ask that 
17:23:15  <bdbaddog>     some .net file? 
17:23:22  <[GregNoel](GregNoel)>     Man page says "preprocessed assembler" 
17:23:33  <[GregNoel](GregNoel)>     (It's in the spreadsheet comments.) 
17:23:36  <Garyo>        for what OS? 
17:23:44  <[GregNoel](GregNoel)>     Any? 
17:23:56  <Garyo>        what man page did you find it in? 
17:24:24  <[GregNoel](GregNoel)>     SCons man page. 
17:24:48  <[GregNoel](GregNoel)>     We currently preprocess those files, but apparently don't scan them for dependencies. 
17:24:56  <Garyo>        Oh?!  Wow, that's a surprise! 
17:25:05  <[GregNoel](GregNoel)>     It was to me, too. 
17:25:09  <Garyo>        OK, I guess you guys are right, add it to the list. 
17:25:37  <Garyo>        I'll do that too.  The work part is trivial. 
17:25:49  <Garyo>        2.1 p4 garyo +easy 
17:25:51  <[GregNoel](GregNoel)>     OK, done, but watch for side-effects: it may try to compile the file. 
17:26:07  <Garyo>        ok, put a note in if you don't mind... 
17:26:17  <[GregNoel](GregNoel)>     Wilco 
17:26:33  <[GregNoel](GregNoel)>     2574 
17:27:02  <[GregNoel](GregNoel)>     Another trivial change, but would work better post-2.0. 
17:27:16  <Garyo>        Agreed.  Post 2.0. 
17:27:33  <Garyo>        2.1 p2, who? 
17:28:08  <[GregNoel](GregNoel)>     Not seeing any volunteers... 
17:28:19  <[GregNoel](GregNoel)>     I can't take it; I'll be recovering. 
17:28:36  <Garyo>        Understood.  Assign it to me then, I'll delegate if needed. 
17:28:41  <[GregNoel](GregNoel)>     done 
17:28:48  <[GregNoel](GregNoel)>     2575 
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 
17:29:22  <Garyo>        That's an excellent idea. 
17:29:39  <Garyo>        Jason, can you propose that to the OP and ask for a new patch? 
17:29:50  <Jason_at_Intel>       (zipfile in Parts :-) .. not as good as raw zip however in some cases) 
17:30:09  <Jason_at_Intel>       sure.. main problem is the call more than once issue 
17:30:29  <Jason_at_Intel>       the builders think the output is more than one environment 
17:30:16  <[GregNoel](GregNoel)>     Um, it would have to work for all builders, not just this one. 
17:30:32  <Garyo>        Would it, Greg?  Couldn't it just be an env override? 
17:31:07  <[GregNoel](GregNoel)>     No, I don't think so.  Think of LaTeX, for example, which wants to run in the build directory. 
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) 
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 
17:31:46  <Garyo>        Greg: I don't think tar/zip need to *run* in any particular dir, they just need a reference point. 
17:32:39  <Garyo>        OK, maybe this is more complicated than it seems at first. 
17:32:40  <Jason_at_Intel>       however for 2575 his patch will work.. it will just break -j builds 
17:33:00  <Garyo>        Jason: that worries me. 
17:33:07  <[GregNoel](GregNoel)>     Actually, tar/zip can have multiple changes of directory in them; that's why I like the solution in 1890. 
17:33:31  *      Garyo looks at 1890 
17:34:15  <Jason_at_Intel>       ie use the tarfile module? 
17:34:23  <Garyo>        I see, use tarfile instead of calling tar.  I totally agree. 
17:34:34  <[GregNoel](GregNoel)>     Garyo, basically, each entry is a duple of (name-in-archive, File-node). 
17:34:48  <Jason_at_Intel>       I have an impl in Parts for this 
17:34:59  <Jason_at_Intel>       but again i don't have it support more than one call 
17:35:15  <Garyo>        It's a call-once-with-all-sources builder? 
17:35:28  <Jason_at_Intel>       yep 
17:35:44  <Jason_at_Intel>       again the src_dir overide upsets teh builders 
17:35:54  <Jason_at_Intel>       spits out warnings or errors 
17:35:58  <Garyo>        Not ideal, of course, but probably best we can do given builder limitations 
17:36:08  <[GregNoel](GregNoel)>     I have a functional prototype for 1890, but I've been waiting for post-2.0 to implement it. 
17:36:29  <Garyo>        And calling with a single src dir is probably 90% of all use cases anyway. 
17:37:11  <Jason_at_Intel>       can you look at [*checkout*/parts/trunk/parts/parts/pieces/](*checkout*/parts/trunk/parts/parts/pieces/ 
17:37:13  <[GregNoel](GregNoel)>     Then why not base it off of chdir=?  It's the effect that counts, not the actual functioning. 
17:37:51  <Garyo>        because of breaking -j, right? 
17:38:10  <Jason_at_Intel>       I think the chdir in SCons means current dir change 
17:38:26  <Jason_at_Intel>       Scons needs a new idea to support the "root" area to use 
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. 
17:38:40  <Jason_at_Intel>       src_dir is what i would propose 
17:39:04  <[GregNoel](GregNoel)>     I don't agree. 
17:39:26  <Garyo>        don't agree w/ src_dir, or don't agree w/ my assignment? 
17:39:27  <Jason_at_Intel>       to me .. not gary .. correct? 
17:39:58  <[GregNoel](GregNoel)>     don't agree with src_dir; again, the effect is the requirement, not the actuality. 
17:40:15  <Jason_at_Intel>       ?? 
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. 
17:40:52  <[GregNoel](GregNoel)>     Yes 
17:41:01  <Garyo>        Might require a little core patching but not impossible of course. 
17:41:15  <Jason_at_Intel>       that is fine.. then does this mean we will fix command to do the same 
17:41:21  <Garyo>        (like a "builder_wants_chdir" flag or something) 
17:41:35  <Jason_at_Intel>       will it out add a cd <dir> && to the command? 
17:42:15  <Garyo>        Jason: at least the infrastructure would be there to handle it that way if we wanted to. 
17:42:22  <[GregNoel](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=. 
17:43:07  <[GregNoel](GregNoel)>     If we change that paradigm, we need to make it consistent. 
17:42:57  <Jason_at_Intel>       so back to the issue 
17:43:02  <Jason_at_Intel>       this is a patch 
17:43:11  <Jason_at_Intel>       that is invalid? 
17:43:13  <Garyo>        Let's not say it's invalid then, but we think there's a better method. 
17:43:24  <[GregNoel](GregNoel)>     Garyo, yes. 
17:43:51  <Jason_at_Intel>       i see... not sure what the better method you have in mind is 
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. 
17:44:29  <Jason_at_Intel>       agree 
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. 
17:45:11  <[GregNoel](GregNoel)>     And you could have chdir= on each builder call. 
17:45:13  <Jason_at_Intel>       I guess... but you woudl always want it on.. never off 
17:45:20  <Garyo>        (Greg, is that basically your idea?) 
17:45:42  <[GregNoel](GregNoel)>     Still designing on the fly, but yes, I think so. 
17:45:44  <Garyo>        Jason: we can't turn it on for all builders because most of them don't understand it. 
17:45:59  <loonycyborg>  chdir is clearly hack in this case. 
17:46:26  <[GregNoel](GregNoel)>     Hi, Sergey; glad you could join us.  Do you think users would understand a distinction there? 
17:46:29  <loonycyborg>  There should be more flexible ways to specify paths that'll be stored in the archive, 
17:46:32  <Garyo>        loonycyborg: yes, we'd be "repurposing it" a bit. 
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 
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. 
17:47:45  <Jason_at_Intel>       agree 
17:48:02  <[GregNoel](GregNoel)>     OK, then what should we do with the ticket? 
17:48:37  <[GregNoel](GregNoel)>     I'll suggest deferring to the mailing list. 
17:48:43  <Garyo>        How about this: mark it 2.1 p2, but with a note to say revisit at that time and discuss. 
17:48:58  <Jason_at_Intel>       +1 
17:49:00  <[GregNoel](GregNoel)>     Yes 
17:49:08  <bdbaddog>     +1 
17:49:08  <Garyo>        (rather than have a complete implementation by that time) 
17:49:16  <[GregNoel](GregNoel)>     done 
17:49:18  <Garyo>        good, consensus! 
17:53:13  <loonycyborg>  Zip builder should store paths relative to shortest common path of sources by default IMO.. 
17:53:35  <[GregNoel](GregNoel)>     And that's what I'd like to do with 1890. 
17:54:24  <[GregNoel](GregNoel)>     Always put in a duple with relative path and File node. 
17:53:49  <Garyo>        loonycyborg: put a note in those 2 tickets if you want. 
17:54:54  <Garyo>        I like explicit rather than implicit in general though, even if it's a little more typing. 
17:55:19  <[GregNoel](GregNoel)>     Garyo, yes. 
17:55:02  <Jason_at_Intel>       lonnycyborg.. I agree.. that is what I have in Parts as well 
17:55:04  <[GregNoel](GregNoel)>     Remember, relative path is expensive to calculate; should try to avoid it when possible. 
17:55:06  <Garyo>        ...but we're trying to design it here. 
17:55:15  <Garyo>        let's not. 
17:49:37  <[GregNoel](GregNoel)>     2576 
17:50:00  <Garyo>        2576 looks like good potential for Russel to feed Steven things. 
17:50:28  <[GregNoel](GregNoel)>     Yes. 
17:51:13  <[GregNoel](GregNoel)>     I wonder if "anytime" would work for this, as they work out the interaction details. 
17:51:19  <Garyo>        2.x p3, Steven to own, and work w/ Russel? 
17:51:57  <Garyo>        (Or vice versa, Russel to own, delegate work to Steven?) 
17:52:08  <[GregNoel](GregNoel)>     I could buy 2.x p3, but I'd like to see a procedure worked out first. 
17:52:37  <[GregNoel](GregNoel)>     Russel to own during design, Steven to own during implementation? 
17:52:57  <Garyo>        OK then, let's ask Steven to work something like that out & revisit next meeting. OK? 
17:53:12  <[GregNoel](GregNoel)>     yes, I like that. 
17:53:18  <bdbaddog>     +1 
17:53:25  <Jason_at_Intel>       +1 
17:55:40  <[GregNoel](GregNoel)>     We seem to have covered the issues; I have one thing on schedule. 
17:56:21  <[GregNoel](GregNoel)>     I can't make the next meeting; should we think about one week or three weeks for the next party? 
17:55:21  <Jason_at_Intel>       so 1.3 
17:55:37  <Garyo>        Yes, 1.3.  I'm in favor of moving aggressively to release. 
17:56:13  <Garyo>        I have 2 issues to test and one which won't get into 1.3. 
17:56:45  *      loonycyborg really hopes that 2443 will be fixed in 1.3 
17:57:30  <Garyo>        :-( that's my one I thought wouldn't make it.  I'll make an effort for it. 
17:57:32  <[GregNoel](GregNoel)>     loonycyborg, if the current checkpoint is the final candidate, that won't happen.  Sorry. 
17:57:34  <bdbaddog>     seems unlikely. we're on the runway to 1.3 launch.. 
17:58:01  <Garyo>        They're right, things I've looked at would destabilize. 
17:59:00  <Jason_at_Intel>       hmm  2443 works for me. 
17:58:23  <Garyo>        Let's get 1.3 and 2.0 out asap. 
17:58:39  <Garyo>        Then we can get back on a shorter & less constricted release cycle. 
17:58:57  <bdbaddog>     yaha 
17:59:11  <bdbaddog>     so 1.3 this weekend then? 
17:59:14  <[GregNoel](GregNoel)>     Can you get back to all the people who've had problems with vs_revamp and get them to try the checkpoint? 
17:59:33  <[GregNoel](GregNoel)>     If so, this weekend sounds fine to me. 
17:59:35  <Garyo>        Greg: yes, those are the 2 issues on my test list. 
17:59:57  <Garyo>        Bill: I'll try to review the release docs soon.  I'm happy to help wordsmith. 
18:00:56  <Garyo>        Is the release process pretty much as documented on the wiki now? 
18:02:09  <Garyo>        I'll be skiing this wkend, but around this week and next. 
18:02:12  <bdbaddog>     yes. though I might move a few steps around to streamline 
18:02:36  <Garyo>        OK, let me help; you've done a lot. 
18:03:00  <Garyo>        Do you think this wkend is possible? 
18:03:36  <bdbaddog>     to get feedback on the couple of issues msvs/vc/sdk which have been reported? 
18:04:13  <Garyo>        I think that should be possible. 
18:04:21  <[GregNoel](GregNoel)>     If you can get it done this weekend, I can start on 2.0 on Tuesday after I get back from Cabo. 
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. 
18:05:31  <bdbaddog>     there's two more. 
18:05:55  <bdbaddog>     this one: []( 
18:06:23  <Garyo>        Oh right, missing gdi32.lib. 
18:06:50  <bdbaddog>     and one with vc2010rc + a bunch of other isntalled vc's and it not picking  up the requested one. 
18:08:00  <bdbaddog>     I had a win7 license from when they gave out the free trials, but it's expired. 
18:07:51  <Garyo>        I think we have to draw the line somewhere or we'll never get it out. 
18:08:08  <bdbaddog>     yeah. I think so too. 
18:08:11  <bdbaddog>     back in a minute.. 
18:08:12  <Garyo>        I have a win7 machine now. 
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.) 
18:09:22  <Jason_at_Intel>       what is win7 needed for? 
18:09:54  <Garyo>        I think bdbaddog's 2nd issue, from the ML. 
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. 
18:10:24  <Jason_at_Intel>       ahh 
18:10:49  <Jason_at_Intel>       was masm tool fixed to use ml64? 
18:11:04  <Garyo>        I don't remember. 
18:11:10  <bdbaddog>     donno. 
18:11:13  <Garyo>        Try it :-) 
18:11:22  <bdbaddog>     or check the bug to see if it's marked fixed. 
18:11:40  <Jason_at_Intel>       I think it still uses ml 
18:13:15  <Jason_at_Intel>       yep.. still broken 
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. 
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() 
18:12:49  <Garyo>        That's usually what that means. 
18:14:04  <bdbaddog>     I'm guessing somehow the sdk/vc logic combo is not quite right, but only in some corner cases. 
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. 
18:13:26  <Garyo>        Sorry.  2.1. 
18:14:14  <bdbaddog>     I hear u. I want 1.3 done. 
18:14:19  <bdbaddog>     I'm tired of py 1.5.2 
18:14:19  <Jason_at_Intel>       on that i have mirrored this in Parts (with part-site) 
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.) 
18:15:34  <Jason_at_Intel>       so go with what we have with vs_revamp and patch in 2.0? 
18:15:57  <Garyo>        Jason: yes, or 2.1 actually.  2.0 = 1.3 with python floor update. 
18:15:58  <bdbaddog>     what's in vs_revamp? it's all on trunk 
18:16:11  <Garyo>        yes, trunk. 
18:16:25  <Jason_at_Intel>       sorry mean the "feature" not branch 
18:16:51  <Jason_at_Intel>       so this mean 2.0 will be soon after 1.3? 
18:17:06  <[GregNoel](GregNoel)>     I'll have three weeks, 
18:17:42  <[GregNoel](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. 
18:17:06  <Garyo>        hopefully! 
18:17:07  <bdbaddog>     yes. that's the plan. 
18:17:19  <Jason_at_Intel>       great! 
18:17:22  <bdbaddog>     no features in 2.0, just remove 1.5.2->2.3 code. 
18:17:24  <bdbaddog>     right? 
18:17:32  <Jason_at_Intel>       2.4? 
18:17:34  <Garyo>        agreed. 
18:17:49  <Jason_at_Intel>       thought 2.3 was broken on some platforms 
18:18:00  <bdbaddog>     we're dropping 2.3 
18:18:04  <bdbaddog>     and below. 
18:18:09  <Garyo>        2.4 is the new floor. 
18:18:13  <bdbaddog>     yes. 
18:18:17  <Jason_at_Intel>       :-) 
18:19:04  <Garyo>        ok, let's do it! 
18:19:13  <bdbaddog>     k. 
18:19:24  <[GregNoel](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. 
18:19:48  <bdbaddog>     should we make the call next tues on 1.3? 
18:20:00  <Garyo>        +1 
18:20:00  <Jason_at_Intel>       +1 
18:20:07  <bdbaddog>     or we can handle on release mailing list if things are resolved sooner. 
18:20:23  <Garyo>        fine. 
18:21:01  <[GregNoel](GregNoel)>     One week, then? 
18:21:16  <Garyo>        good with me. 
18:21:34  <bdbaddog>     k. virtually c u all then. 
18:21:44  <Jason_at_Intel>       same! 
18:21:49  <[GregNoel](GregNoel)>     OK, see you all in one week. 
18:21:54  <Garyo>        bye 4 now. 
18:22:00  <Jason_at_Intel>       bye 
18:22:04  <[GregNoel](GregNoel)>     Got to go, dinner is calling. 
18:22:12  <bdbaddog>     l8r 
18:22:22  <[GregNoel](GregNoel)>     G'day all. 
18:22:29  *      [GregNoel](GregNoel) has been marked as being away 
18:23:38  *      bdbaddog (~[]( has left #SCONS 
18:32:20  *      Jason_at_Intel has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.5.3/20090824101458]) 
18:38:08  *      loonycyborg has quit (Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz) 
18:45:54  *      Garyo has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.5.8/20100202165920]) 

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.