Clone wiki

SCons / BugParty / IrcLog2010-05-11

The SCons wiki has moved to

16:41:21  *      garyo (~[]( has joined #SCONS 
16:48:31  *      Jason_at_Intel (~[chatzilla@](mailto:chatzilla@ has joined #SCONS 
16:54:00  *      bdbaddog (~[]( has joined #SCONS 
16:59:05  *      [GregNoel](GregNoel) is no longer marked as being away 
16:59:22  *      sgk (~sgk@nat/google/x-vbtwdjatbsgoccdr) has joined #SCONS 
16:59:23  <[GregNoel](GregNoel)>     Hi, guys; I don't see Steven yet, but are we ready to go otherwise? 
16:59:42  <[GregNoel](GregNoel)>     Oops, there he is. 
16:59:42  <sgk>  just got here 
16:59:46  <Jason_at_Intel>       he just logged in 
16:59:52  <sgk>  i'm sneaky that way 
17:00:00  <[GregNoel](GregNoel)>     {;-} 
17:00:09  <garyo>        Hi folks 
17:00:14  <Jason_at_Intel>       hi all 
17:00:29  <bdbaddog>     Hi! 
17:00:39  <sgk>  ready when everyone else is 
17:00:41  <[GregNoel](GregNoel)>     2609, consensus 
17:00:52  <[GregNoel](GregNoel)>     2498, consensus 
17:00:59  <garyo>        yep 
17:01:00  <[GregNoel](GregNoel)>     2611 
17:01:23  <garyo>        Looks like Steven's to me... 
17:01:29  <sgk>  yep 
17:01:40  <garyo>        2.x p3 sgk? 
17:01:46  <sgk>  Jaston_at_Intel:  good point re: grouping 
17:02:02  <Jason_at_Intel>       thanks 
17:02:08  <sgk>  the intent is that our API is supposed to look like optparse's enough to allow things like that 
17:02:18  <sgk>  but we probably have to expose some additional pieces to make grouping work 
17:02:11  <Jason_at_Intel>       it is clear to see in Parts 
17:02:19  <Jason_at_Intel>       -h is useless 
17:02:22  <[GregNoel](GregNoel)>     At 2.x p3, it's possible that it might be overrun by doing something with IAPAT. 
17:02:39  <sgk>  [GregNoel](GregNoel):  fair enough, if that happens 
17:02:57  <Jason_at_Intel>       I making a first stab at this in part with my own iapat light object 
17:03:21  <garyo>        I'll be interested to see it 
17:03:21  <[GregNoel](GregNoel)>     I have a wiki page somewhere with some thoughts about how help text should be displayed, but I can't find it quickly; it covers things like groupings, but ... 
17:03:58  <[GregNoel](GregNoel)>     ... it was intended to be backward compatible, so it didn't have a lot of wiggle room. 
17:03:50  <Jason_at_Intel>       would like to read your thoughts.. I will look for it myself when i get back to that 
17:03:50  <sgk>  btw, what does IAPAT specifically stand for? 
17:04:07  <garyo>        Info About Platform And Tools :) 
17:04:14  <sgk>  k, thx 
17:04:22  <Jason_at_Intel>       I had a better name.. but forgot to write it down... 
17:04:35  <garyo>        Greg named it that because it was so ugly we'd be forced to not use it, I think. 
17:04:43  <[GregNoel](GregNoel)>     exactly 
17:04:40  <garyo>        So don't. 
17:04:54  <sgk>  IAPAT works, the SConsFutureProjects wiki page shows up #5 when you google it 
17:04:56  <Jason_at_Intel>       :-) 
17:05:11  <garyo>        :-/ 
17:05:36  <sgk>  back to the task at hand... 
17:05:41  <[GregNoel](GregNoel)>     In any event, I'll go with 2.x p3 for 2611 
17:05:42  <sgk>  2611:  2.x p3 sgk for a quick fix 
17:05:49  <garyo>        agreed. 
17:05:50  <[GregNoel](GregNoel)>     done 
17:06:03  <sgk>  do we need an issue for longer-term "clean up Help()" ? 
17:06:11  <garyo>        sgk: +1 
17:06:42  <garyo>        (specifically, handle grouping I guess -- otherwise it's not so bad now really) 
17:06:29  <[GregNoel](GregNoel)>     Hmmm...  Maybe [FutureProjects](FutureProjects)? 
17:06:38  <sgk>  [GregNoel](GregNoel)++ 
17:06:51  <sgk>  we have enough issues to sort through as it is 
17:07:11  <garyo>        ok I guess 
17:07:18  <[GregNoel](GregNoel)>     I'll add it to [FutureProjects](FutureProjects) 
17:07:20  <sgk>  I'll add it to SConsFutureProjects while we're discussing the rest 
17:07:29  <sgk>  too late, i already clicked... :-) 
17:07:32  <garyo>        thx 
17:07:43  <[GregNoel](GregNoel)>     sgk, that'll work, too... 
17:07:29  <Jason_at_Intel>       fyi 
17:07:47  <Jason_at_Intel>       the issue is that [AddOption](AddOption) conflict with this at times 
17:08:19  <sgk>  Jason_at_Intel:  "...conflict with this..."  this == ?? 
17:09:24  <Jason_at_Intel>       in getting help -h show Varibles.. but hides options and addOption show user --<value>.. you can can't see both  and sometime the addoption don't show at all 
17:06:02  <[GregNoel](GregNoel)>     2612 consensus 
17:07:55  <garyo>        2612, 2613 consensus both 
17:08:05  <[GregNoel](GregNoel)>     2614 
17:08:39  <[GregNoel](GregNoel)>     It should use Action._subproc() to get the right shell environment. 
17:09:06  <garyo>        right meaning default? 
17:09:53  <[GregNoel](GregNoel)>     Default, picked up from env, whatever. 
17:10:17  <garyo>        I see, there's a function in there get_default_ENV. 
17:10:32  <garyo>        But for running bat scripts shouldn't we start with as little imported as possible? 
17:10:40  <[GregNoel](GregNoel)>     Yeah, that's a worst case, but it'll do the right thing. 
17:11:21  <Jason_at_Intel>       have we tried to build with vs2010 and a windows server system? 
17:11:33  <garyo>        Jason: I bet not. 
17:11:39  <Jason_at_Intel>       i have reason to believe that the script don't work there 
17:11:48  <garyo>        But why do you ask?  Does its bat script need shell vars? 
17:12:14  <Jason_at_Intel>       well the .net stuff will not setup correctly 
17:12:32  <Jason_at_Intel>       so unless you import it from the shell it might not work 
17:12:53  *      sgk now agrees that Action._subproc() should be used here; we need more consistency w.r.t. invoking commands, not less 
17:13:00  <garyo>        Right now it's importing the user's whole env.  We're talking about cutting out most/all of that. 
17:13:21  <bdbaddog>     is that a 1.3 fix? 
17:13:28  <bdbaddog>     Action._subproc() ? 
17:13:30  <garyo>        sgk/Greg: I see the point about Action._subproc.  It's quite valid. 
17:13:38  <Jason_at_Intel>       Action._subproc (.. does this do a subversion call?) 
17:14:00  <sgk>  no, it's just a way to invoke an external command (subprocess) 
17:14:13  <sgk>  using the Environment's ENV, not whatever's in os.environ 
17:14:21  <Jason_at_Intel>       sorry ment subprcess 
17:14:50  <sgk>  one of the dumber early SCons design decisions was using the user's external environment to toolchain detection 
17:14:54  <sgk>  instead of ENV['PATH'] 
17:14:51  <Jason_at_Intel>       does it hide the output, or have an option for that? 
17:14:57  <garyo>        Jason: yes, most of it is setting up the proper env to pass to subprocess.Popen. 
17:15:28  <garyo>        Jason: it handles stdin/stdout/stderr. 
17:15:46  <Jason_at_Intel>       cool.. have have my own api for this... but would like to use a Scons one if it exists 
17:16:02  <garyo>        bdbaddog: ideally yes for 1.3, it is a regression after all.  What do you think? 
17:16:16  <garyo>        jason: it's in 
17:20:09  <garyo>        With _subproc, we'd pass env=None here since there's no env at that point. 
17:20:21  <garyo>        But it should still work OK. 
17:17:15  <bdbaddog>     garyo: I'll have to take a look at the change, but likely 1.3. 
17:17:23  <bdbaddog>     though pre/post 1.3.1 ? 
17:17:42  <[GregNoel](GregNoel)>     We're taking too long to decide; if we can't come to a resolution soon, it'll have to go to email. 
17:17:48  <bdbaddog>     yes. I agree. 
17:17:56  <garyo>        1.3.1 if possible. 
17:18:05  <sgk>  agreed, 1.3.1 if possible 
17:18:18  <sgk>  unless it would hold up too long 
17:18:20  <garyo>        (that way maybe we never have to do 1.3.2 :-)) 
17:18:36  *      sgk likes the sound of no 1.3.2 
17:18:45  <garyo>        1.3.1, p3.  I'll help w/ it. 
17:18:49  <bdbaddog>     I'd put $10 on there'll be a 1.3.2 
17:18:50  <[GregNoel](GregNoel)>     Since it's a regression, 1.3.1 p1? 
17:18:57  <sgk>  ++ 
17:19:10  <bdbaddog>     k. 
17:19:20  <[GregNoel](GregNoel)>     done 
17:19:21  <bdbaddog>     I'll take a wack at it tonight and push another checkpiont if I can. 
17:19:37  <sgk>  and it can be pushed if there's a good reason (it's too hairy, unintended side effects, etc.) 
17:19:29  <[GregNoel](GregNoel)>     2615? 
17:20:02  <[GregNoel](GregNoel)>     There's basic agreement on 2615, but the details need to be pinned down. 
17:20:25  <sgk>  which 2615 details?  2.2 vs. 2.1 ? 
17:20:47  <[GregNoel](GregNoel)>     sgk, yes, also priority and owner. 
17:20:40  <bdbaddog>     2.1 
17:21:09  <garyo>        2.1 
17:21:05  <sgk>  ah, I thought +Easy obviated those 
17:21:10  <sgk>  but I guess not for 2.1 / 2.2 
17:21:27  <sgk>  (< 5 minutes to interrupt to board shuttle) 
17:21:37  <[GregNoel](GregNoel)>     sgk, yes, for 2.x it's OK, but not for closer issues. 
17:21:56  <garyo>        p2 since it's a silent failure? 
17:22:01  <sgk>  p2 sounds good 
17:22:06  <Jason_at_Intel>       in action._subproc it seem you want to pass env={}.. but you can't as there is a arg with than value 
17:22:13  <sgk>  i already looked, i can take if no one else volunteers 
17:22:20  <[GregNoel](GregNoel)>     2.1 p2 works for me. 
17:22:53  <sgk>  oh, wait, i was thinking about 2618 
17:22:57  <garyo>        jason: env=None will work. 
17:23:14  <garyo>        2615: I can do it. 
17:23:29  <[GregNoel](GregNoel)>     OK, that works for me. 
17:23:33  <sgk>  thx 
17:23:39  <[GregNoel](GregNoel)>     2.1 p2 Gary. 
17:23:46  <[GregNoel](GregNoel)>     2617? 
17:23:50  <[GregNoel](GregNoel)>     consensus 
17:24:02  <[GregNoel](GregNoel)>     2618, consensus 
17:24:10  <[GregNoel](GregNoel)>     2619, consensus 
17:24:18  <[GregNoel](GregNoel)>     2620 
17:24:31  <garyo>        consensus too, I agree w/ wontfix 
17:24:38  <[GregNoel](GregNoel)>     done 
17:24:42  <sgk>  agreed 
17:24:49  <[GregNoel](GregNoel)>     2621 
17:25:01  <sgk>  put our time into a framework for externally-developed tools 
17:25:05  <garyo>        let's try to make them do it externally, see if it works. 
17:25:24  <[GregNoel](GregNoel)>     (garyo, BTW, both go and vala generate C-compatible code) 
17:25:26  <sgk>  guess that raises the priority of some of the refactoring to support that 
17:25:30  <garyo>        (did that make sense?) 
17:25:35  <sgk>  shuttle's here, biab 
17:25:38  *      sgk has quit (Quit: sgk) 
17:25:39  <Jason_at_Intel>       Gary how? you get a Eenv setup form teh default toolchain when you process the key error in get_Default_ENV and call SCons.Environment.Environment()['ENV'] 
17:25:56  <garyo>        Greg: I didn't know that about Go.  But of course you're right. 
17:26:18  <[GregNoel](GregNoel)>     garyo, it uses GCC's backend. 
17:26:46  <garyo>        Greg: so both of them will be good testcases to see if this can be done outside the core. 
17:26:54  <[GregNoel](GregNoel)>     I agree. 
17:26:24  <garyo>        Jason: right, you'll end up in get_default_ENV which is fine. 
17:26:43  <Jason_at_Intel>       but not {} which is clean in cases like msvc 
17:26:44  <[GregNoel](GregNoel)>     so 2621 wontfix? 
17:26:56  <garyo>        Greg: I agree w/ that. 
17:26:54  <[GregNoel](GregNoel)>     done. 
17:27:02  <[GregNoel](GregNoel)>     2622? 
17:27:13  <garyo>        agree w/ sgk. 
17:27:18  <garyo>        2.1 p1 sk 
17:27:25  <[GregNoel](GregNoel)>     done 
17:27:34  <[GregNoel](GregNoel)>     2623, consensus 
17:27:41  <[GregNoel](GregNoel)>     2624 
17:28:05  <[GregNoel](GregNoel)>     I'll go with 2.1 p2, but it needs an owner. 
17:28:18  <Jason_at_Intel>       2624 was dup? 
17:28:21  *      sgk (~[sgk@](mailto:sgk@ has joined #SCONS 
17:28:37  <garyo>        Seems a lot like 2615 which is mine.  I'll at least try it. 
17:28:38  <sgk>  back 
17:28:53  <sgk>  which? 
17:29:07  <[GregNoel](GregNoel)>     sgk, welcome; garyo, I'll agree; sgk, 2624. 
17:29:09  <garyo>        we're on 2624. 
17:29:28  <sgk>  yeah, sounds right 
17:29:37  <[GregNoel](GregNoel)>     sonw 
17:29:41  <[GregNoel](GregNoel)>     oops, done 
17:29:47  <sgk>  i like "sonw" myself 
17:29:52  <[GregNoel](GregNoel)>     2625 
17:29:54  <garyo>        2624: 2.1 p2 garyo, and I think 2625 is the same kind of thing too, right? 
17:30:17  <sgk>  yeah, if you want it 
17:30:19  <garyo>        Just your basic error handling?  I can do that. 
17:30:23  <sgk>  cool 
17:30:43  <[GregNoel](GregNoel)>     works for me; same milestone/pri? 
17:30:55  <garyo>        yes. 
17:31:01  <[GregNoel](GregNoel)>     done 
17:31:13  <[GregNoel](GregNoel)>     2626, consensus 
17:31:21  <[GregNoel](GregNoel)>     Wow, we're done.... 
17:31:29  <sgk>  excellent 
17:31:38  <sgk>  i was surprised by how many new ones we had to go through 
17:31:44  <sgk>  people must be using the software, or something... 
17:31:48  <garyo>        :-) 
17:31:55  <[GregNoel](GregNoel)>     And there are five more since Saturday 
17:31:55  <bdbaddog>     yes. lots of email traffic on lists too of late. 
17:32:05  <bdbaddog>     DRCS discussion anyone? 
17:32:08  <sgk>  any other discussion topics? 
17:32:13  <sgk> that one... 
17:32:15  <sgk>  :-) 
17:32:17  <bdbaddog>     or 2.0 and how far from being ready? 
17:32:25  <sgk>  2.0 first 
17:32:27  <garyo>        Has anyone tried the 2.0 checkpoint yet? 
17:32:36  <garyo>        I mean on real code? 
17:32:37  <Jason_at_Intel>       I tested it.. it is working great for me so far 
17:32:39  <bdbaddog>     ran runtests on all the packages. 
17:32:58  <Jason_at_Intel>       I built all our product with it ( and Parts .. no issues found so far) 
17:33:16  <Jason_at_Intel>       which is about 6 different product at the moment 
17:33:03  <garyo>        I want to try it tomorrow on my win7 box on our real codebase.  I'll let you know. 
17:33:10  <bdbaddog>     x64 ? 
17:33:12  <garyo>        Jason: that's impressive. 
17:33:12  <[GregNoel](GregNoel)>     I'm waiting for bug reports 
17:33:17  <sgk>  [GregNoel](GregNoel):  are there any additional nice-to-have issues for 2.0 that we kicked to lower priority? 
17:33:33  <sgk>  but that we should maybe try to get in for release? 
17:33:41  <[GregNoel](GregNoel)>     The warnings need to be changed to errors 
17:34:16  <[GregNoel](GregNoel)>     and converting [UserFoo](UserFoo) to builtin classes is scheduled for 2.1. 
17:33:30  <garyo>        bdbaddog: I'll build x64 and x86. 
17:33:31  <Jason_at_Intel>       used win7 x64 
17:33:42  <Jason_at_Intel>       have not tried linux yet 
17:33:45  <Jason_at_Intel>       or mac 
17:33:56  <bdbaddog>     we need to push some bug fixes from 1.3.x Ithink for MSVC 
17:34:02  <garyo>        OK, maybe I'll try linux tmw instead of Win. 
17:34:26  <sgk>  bdbaddog:  how many 1.3.x changes in the queue?  enough to check by hand? 
17:34:36  <garyo>        bdbaddog: you're right, 2.0 has to have the 1.3.x fixes (there aren't many) 
17:34:40  <bdbaddog>     hmm. I'll have to diff the msvc sutff. 
17:34:45  <bdbaddog>     shouldnt' be much. 
17:34:58  <bdbaddog>     but will include this latest issue from today right? 
17:34:46  <Jason_at_Intel>       what is teh view in using new style class for all the Scons classes? 
17:35:21  <sgk>  bdbaddog:  yes, at this point, anything in 1.3.[1x] sould go in 2.0 to avoid regressions 
17:35:26  <sgk>  barring good reasons to the contrary 
17:35:01  <sgk>  i thought bdbaddog did one 1.3.x fix earlier on that [GregNoel](GregNoel) backed out of trunk 
17:35:15  <bdbaddog>     didn't know it got backed out. 
17:35:40  <sgk>  it did, but then it seemed to have gotten put back in 
17:35:51  <sgk>  it got backed out to keep the fixer work on a stable base 
17:36:03  <sgk>  since there was a lot of stuff happening 
17:35:59  <bdbaddog>     k. 
17:36:20  <garyo>        anyway, we can pretty easily merge it now I think. 
17:36:25  <bdbaddog>     o.k. will do. 
17:36:30  <sgk>  Jason_at_Intel:  we should transition to using new-style classes for everything 
17:36:42  <Jason_at_Intel>       I agree 
17:36:41  <sgk>  [GregNoel](GregNoel):  think we should do that for 2.0? 
17:36:53  <garyo>        Isn't that a huge change? 
17:37:03  <sgk>  theoretically, no 
17:37:16  <sgk>  syntactically, it's just adding deriving all classes from (object) 
17:36:53  <Jason_at_Intel>       I was think we do want that for 2.0 
17:37:09  <Jason_at_Intel>       just change class XXX(object) 
17:37:10  <[GregNoel](GregNoel)>     sgk, new-style classes won't work for everything; I've been burned trying to convert some.  [NullSeq](NullSeq) comes to mind. 
17:37:25  <sgk>  ugh 
17:37:45  <garyo>        They're faster, right?  Maybe start with Environment, Node, FS? 
17:38:03  <Jason_at_Intel>       I think there will be benefit in doing this long term 
17:38:03  <bdbaddog>     can fixer do that? 
17:38:49  <garyo>        (silence) 
17:39:04  <sgk>  yeah, but what we probably really want is to still do them one by one with testing to isolate problems 
17:39:17  <bdbaddog>     o.k. 
17:39:24  <sgk>  my system's reasonably fast, I could take a stab at converting whatever doesn't break the tests 
17:39:36  <bdbaddog>     sounds good.. 
17:39:38  <sgk>  that means at least one more checkpoint, of course 
17:39:40  <[GregNoel](GregNoel)>     I'd rather _NOT_ schedule them for 2.0, but if they happen to pass all the tests (which would surprise me, there are some subtle differences we depend on), I'm willing to try. 
17:40:02  <garyo>        sounds good to me 
17:40:16  <sgk>  [GregNoel](GregNoel):  sounds like that strikes the right balance 
17:40:42  <sgk>  okay, so for 2.0 work, i've heard: 
17:40:59  <sgk>  * bdbaddog makes sure all 1.3.x changes are present in trunk 
17:41:14  <sgk>  * sgk takes a stab at converting individual classes to new-style classes 
17:41:15  <bdbaddog>     MSVC changes.. 
17:41:32  <sgk>  in addition to those in 1.3.x ? 
17:41:59  <[GregNoel](GregNoel)>     (finish the list, then talk?) 
17:42:02  <bdbaddog>     sgk: saying the changes I'll migrate from 1.30-> 2.0 would be limited to the msvc changes I've made. 
17:42:08  <bdbaddog>     yes 
17:42:13  <sgk>  * change warnings to errors:  who?  (I can) 
17:42:55  <sgk>  is that it? 
17:42:57  <[GregNoel](GregNoel)>     Warnings==>errors, you're best, but I have a couple of thoughts... 
17:43:40  <[GregNoel](GregNoel)>     Possibly some [UserFoo](UserFoo) to builtin classes, but they've been biting back, probably should leave those to 2.1... 
17:43:46  <sgk>  oh, do we have anything on additional things scheduled for deprecation that need warnings turned on in 2.0? 
17:44:09  <[GregNoel](GregNoel)>     sgk, good point... 
17:44:09  <Jason_at_Intel>       sgk: it would be nice if we have a part like api for printing warning and errors in SCons 
17:44:34  <sgk>  Jason_at_Intel:  agreed, but not for 2.0 
17:44:51  <Jason_at_Intel>       Agreed .. more of 2.x or 3.x feature 
17:45:22  <Jason_at_Intel>       but internally such a fix would help maintainability of the code 
17:45:21  <sgk>  heh 
17:46:45  <[GregNoel](GregNoel)>     I'm sure there are some things that need warnings turned on, but I can't remember what.  Don't we have a wiki page for that? 
17:45:43  <sgk>  []( shows whole bunches of things slated for "Mandatory Warnings" in 1.3 
17:45:57  <sgk>  and "Fatal errors" in 2.0 
17:46:01  <sgk>  looks like we've missed that boat 
17:47:04  <[GregNoel](GregNoel)>     Yep, that's the page. 
17:46:25  <sgk>  eh, some of them we did do, the table is just out of date 
17:46:53  <Jason_at_Intel>       so do make the warning Scons error or do they become python errors.... like env.Copy() for example? 
17:47:03  <sgk>  [GregNoel](GregNoel):  would you have time / energy to go through that table, update it, and isolate anything we should do for 2.0? 
17:47:14  <[GregNoel](GregNoel)>     sgk, I think so. 
17:47:43  <Jason_at_Intel>       as in env.Copy is removed 
17:47:46  <sgk>  * [GregNoel](GregNoel) lists any additional deprecated work 
17:48:18  <sgk>  Jason_at_Intel:  check that wiki page, it has a step-by-step process for deprecating things 
17:48:24  <sgk>  ending up with their complete removal 
17:48:35  <Jason_at_Intel>       ok 
17:48:41  <sgk>  but only after we've given people lots of time to adapt 
17:48:46  <garyo>        (actually that's [DeprecationCycle](DeprecationCycle)) 
17:48:52  <sgk>  ([GregNoel](GregNoel) did the heavy lifting of defining the steps) 
17:49:04  <sgk>  garyo:  ah, right 
17:49:14  <[GregNoel](GregNoel)>     (I think I'm having network problems, my IRC update is in fits and starts and my spreadsheet just crashed.) 
17:49:52  <[GregNoel](GregNoel)>     sgk, can you post that list somewhere? 
17:50:10  <bdbaddog>     sgk: and/or email to release list 
17:50:15  <sgk>  i'll email to release 
17:50:34  <[GregNoel](GregNoel)>     good, thanks 
17:50:51  <bdbaddog>     DRCS then? 
17:51:33  <garyo>        I think the guy today who said any of them can now be fronted by any other, so we should just pick and be done with it, was onto something.  But there's one other important issue: 
17:52:13  <garyo>        github vs. what's mercurial's hub vs. launchpad. 
17:52:25  <bdbaddog>     or google code.. 
17:52:32  <garyo>        yes, that too. 
17:52:35  <sgk>  being able to use subversion to get things from github just feels perverse 
17:52:42  <garyo>        :-) 
17:52:53  <Jason_at_Intel>       so the end result is we dump tigris? 
17:53:05  <sgk>  end result, i think so 
17:53:09  <garyo>        Jason: and/or sourcforge. 
17:53:14  <[GregNoel](GregNoel)>     I'm inclined to think that the shrillness of the debate means there's not enough traction on any of them yet. 
17:53:30  <sgk>  yeah 
17:53:40  <Jason_at_Intel>       then it seems that the site feature are important as well 
17:53:48  <Jason_at_Intel>       since there is bug tracking and such 
17:53:41  <bdbaddog>     I'd vote git or hg, just because I'm already using both of those for different projects. 
17:53:44  <garyo>        Greg: not sure about that.  They're all well abovecritical mass imho. 
17:54:00  <sgk>  i think he means traction within our little circle 
17:54:11  <garyo>        ah, well that I can agree with! 
17:54:33  <[GregNoel](GregNoel)>     sgk, yes (updates still in fits and starts) 
17:54:35  <Jason_at_Intel>       I tend to like launchpad ... 
17:54:35  <bdbaddog>     github is pretty nice for managing different users with pull requests and such 
17:55:02  <sgk>  thinking on this more, i think one of the underlying disconnects 
17:55:15  <sgk>  is that it's not clear how much weight to give certain aspects of the decision 
17:55:40  <sgk>  i'm specifically thinking of whether or not the SVN transition should be a big factor 
17:55:59  <garyo>        what do you mean? 
17:56:24  <sgk>  if we're basically ending up not using SVN (except for read-only browsing) 
17:56:50  <sgk>  then maybe all of the attention on "is hgsubversion / git-svn / bzr-* good enough" is wasted effort 
17:56:30  <bdbaddog>     I think we do a SVN->DRCS and call it a day. SVN dies and/or stays the 1.x repository 
17:57:11  <bdbaddog>     sgk: I totally agree. who cares about SVN, we're gonna end up off it anyway. 
17:57:44  <garyo>        i get it 
17:57:49  <sgk>  my hesitation is that I don't know what hassles we're buying in the release / packaging stuff by going gold turkey on svn 
17:57:57  <Jason_at_Intel>       So what is wrong with SVN as the central hub? 
17:58:06  <sgk>  that stuff is old and hairy as it is 
17:58:07  <bdbaddog>     commit rights management. 
17:58:16  <[GregNoel](GregNoel)>     I'd rather ease into the choice; CVS->SVN was too traumatic, and it was supposed to be simple. 
17:58:28  <bdbaddog>     with git, (or other) we have an owner for a repo which takes pull requests.. 
17:58:29  <Jason_at_Intel>       sure... but that is not really different in DVCS 
17:58:43  <Jason_at_Intel>       you can just make your own branch so do what you like 
17:58:51  <bdbaddog>     jason: take a look at how buildbot manages patches. 
17:59:11  <garyo>        jason: all the *-svn workflows are more complicated than pure hg/git/bzr. 
17:59:28  <bdbaddog>     I knew nothing about git, but I was able to get my patch checked in, and send a pull request to the maintainer. 
17:59:32  <Jason_at_Intel>       I get that 
17:59:43  <Jason_at_Intel>       you can diff different repositories 
17:59:53  <Jason_at_Intel>       makes life easier 
18:00:18  <garyo>        ok, rather than debating the merits of each one, as sgk says let's consider where the weights go. 
18:00:39  <bdbaddog>     []( 
18:00:46  <bdbaddog>     []( 
18:00:41  <sgk>  sounds like what we're really getting to is "what comes after" 
18:00:42  <garyo>        IMHO the hub/site is perhaps as important as the actual s/w, since they're all roughly comparable. 
18:00:48  <sgk>  right 
18:00:52  <sgk>  what garyo said 
18:01:16  <bdbaddog>     I see no reason we must tie DRCS hosting to bugtracking. 
18:01:39  <sgk>  bdbaddog:  fair point 
18:01:41  <bdbaddog>     Simplify the decision. look for best hosting. 
18:01:51  <bdbaddog>     then best bug, or simplify and keep it at tigris. 
18:01:54  <bdbaddog>     for now. 
18:01:55  <[GregNoel](GregNoel)>     The issue tracker is a concern; we may need to stay with Tigris for that.  We have workflows that depend on how the XML for issues is reported. 
18:02:18  <sgk>  okay, let's just say the issue tracker stays at 
18:02:19  <bdbaddog>     [GregNoel](GregNoel): pretty much all bug trackers have xml export at this point. 
18:02:19  <Jason_at_Intel>       I would go for bzr or hg.. git is just window unfriendly 
18:02:29  <sgk>  ain't broke, don't fix it, and simplifies the rest of the decision just a bit 
18:02:37  <bdbaddog>     Then I'd vote for hg. 
18:03:00  <sgk>  Jason_at_Intel:  good point re: windows, i thought about that earlier today but forgot to mention 
18:03:01  <bdbaddog>     but I really like githubs forking/pull request mechanisms if git was a possiblity. 
18:03:03  <garyo>        I'd vote for hg or git. 
18:03:06  <bdbaddog>     or even better gerrit. 
18:03:23  <bdbaddog>     []( 
18:03:33  <garyo>        git isn't as bad on windows as it used to be... but it still is less friendly there. 
18:03:37  <bdbaddog>     it's used by andriod and wraps git with code review 
18:03:44  <sgk>  gerrit scares me a bit because of the back-end automated merge and checkin 
18:04:01  <sgk>  but that was based on early discussions when it was still google internal 
18:04:05  <bdbaddog>     from the podcast it sounds like you do manual merge when there's conflicts 
18:04:28  <garyo>        trac and redmine are also excellent, and support git/hg at least, and maybe bzr 
18:04:29  <sgk>  can, my concern is bad merges that don't conflict 
18:04:46  <bdbaddog>     ahh. o.k. 
18:05:01  <bdbaddog>     can host a code reveiw enging on GAE.. 
18:05:07  <bdbaddog>     engine that is 
18:05:21  <bdbaddog>     anyway.. somewhat secondary. 
18:05:31  <sgk>  gerrit's value add is really the code review process, though, isn't it? 
18:05:35  <bdbaddog>     yes. 
18:05:40  <garyo>        I see 
18:05:49  <sgk>  i don't know if any of us has the cycles for more formal code review 
18:05:51  <bdbaddog>     and it's git compatible so we can migrate to it I think if we choose git. 
18:05:58  <sgk>  even though it'd be a Good Thing conceptually 
18:06:05  <bdbaddog>     sgk:yes 
18:06:10  <garyo>        What I heard above seemed like hg is a noncontroversial choice for most of us. 
18:06:32  <garyo>        Some say git/hg, some say hg/bzr, but nobody seems to be anti-hg. 
18:06:35  <garyo>        ? 
18:06:41  <bdbaddog>     garyo: I'm fine with that. plus it sounds like we could mirror to git, or migrate if it turned out to be a mistake. 
18:06:51  <sgk>  that sounds right 
18:06:58  <garyo>        plus it's in python 
18:06:59  <bdbaddog>     k. so hg, what timeframe? 
18:07:04  <bdbaddog>     2.0? 
18:07:06  <[GregNoel](GregNoel)>     Hg is good with me. 
18:07:08  <sgk>  what's the logical hg host? 
18:07:10  <Jason_at_Intel>       i like lauchpad 
18:07:23  <Jason_at_Intel>       what is the hg equal 
18:07:28  <sgk>  i thought launchpad was bzr ? 
18:07:38  <sgk>  k 
18:07:46  <Jason_at_Intel>       it is 
18:07:50  <sgk> supports hg 
18:07:55  <sgk>  not sure how well, though 
18:08:06  <garyo>        "bitbucket"? 
18:08:06  <bdbaddog>     I'm using for one project. 
18:08:12  <Jason_at_Intel>       not sure of the hg site that would be like that 
18:08:23  <garyo>        bdbaddog: how is it? 
18:08:41  <bdbaddog>     decent, but it's just me right now in the project, so many of the issues dont' come into play 
18:08:48  <garyo>        sgk: we could do worse than 
18:08:51  <bdbaddog>     where's python hosted? 
18:09:07  <[GregNoel](GregNoel)>     I think my update is behind, but NOT 2.0, please.  2.1 maybe. 
18:09:24  <Jason_at_Intel>       bitbucket looks nice 
18:09:55  <garyo>        Agree w/ Greg.  Post-2.0, maybe between 2.0 and 2.1 or something. 
18:10:05  <sgk>  i agree re post-2.0 
18:10:17  <bdbaddog>     k. post 2.0 
18:10:39  <bdbaddog>     I'll create a dummy project on and send out info and we can try it? 
18:11:00  <bdbaddog>     waf is hosted there.. 
18:11:17  <sgk>  excellent!  we're in good company then... :-) 
18:11:48  <sgk>  bdbaddog:  do you want to create "scons" there, or some other experimental name for now? 
18:12:01  <garyo>        Just for info sake, I think python self-hosts their repo. 
18:12:04  <bdbaddog>     experimental. I'll see if I can import scons. 
18:12:28  <garyo>        bdbaddog: see good info in []( 
18:13:02  <sgk>  garyo:  excellent find 
18:13:02  <bdbaddog>     garyo: just sent that via this irc earlier.. ;) 
18:13:20  <garyo>        um, so you did. oops. 
18:13:28  <sgk>  bdbaddog:  excellent find 
18:13:43  <bdbaddog>     sgk: why thank u.. great minds think alike it seems.. 
18:13:49  <sgk>  < 2 minutes to shuttle stop 
18:14:00  <bdbaddog>     k. 
18:14:01  <sgk>  okay, sounds like a plan 
18:14:10  <garyo>        maybe we're done for tonight, good job all 
18:14:14  <bdbaddog>     gnight everyone then.. 
18:14:27  <Jason_at_Intel>       night 
18:14:47  <sgk>  thanks guys 
18:14:49  <sgk>  'night 
18:15:18  *      Jason_at_Intel has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.5.3/20090824101458]) 
18:15:21  <[GregNoel](GregNoel)>     Looks like we're ending.  G'night, all. 
18:15:24  *      sgk has quit (Quit: sgk) 
18:15:35  <garyo>        good night. 
18:15:38  *      garyo (~[]( has left #SCONS 
18:15:48  *      [GregNoel](GregNoel) has been marked as being away