1. SCons
  2. Core
  3. SCons

Wiki

Clone wiki

SCons / BugParty / IrcLog2010-08-03

16:41:49  *      jason_at_intel (~[chatzilla@131.sub-75-207-82.myvzw.com](mailto:chatzilla@131.sub-75-207-82.myvzw.com)) has joined #SCONS 
16:45:32  *      garyo (~[garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com](mailto:garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)) has joined #SCONS 
17:00:22  *      [GregNoel](GregNoel) has arrived and is setting up 
17:01:03  *      bdbaddog (~[bdeegan@adsl-71-131-10-196.dsl.sntc01.pacbell.net](mailto:bdeegan@adsl-71-131-10-196.dsl.sntc01.pacbell.net)) has joined #SCONS 
17:01:57  <[GregNoel](GregNoel)>     I don't see Steven, but it looks like a pretty full house.  Sergey, are you there? 
17:02:10  <loonycyborg>  Yes. 
17:02:14  <garyo>        Hi Sergey! 
17:02:23  <loonycyborg>  Hello. 
17:02:23  <[GregNoel](GregNoel)>     Are we ready to start? 
17:02:40  <garyo>        I think so 
17:02:41  <jason_at_intel>       I am ready 
17:02:45  <jason_at_intel>       are we going to wait for steven? 
17:02:56  <[GregNoel](GregNoel)>     Since it's after 4am for Sergey and he has some insights to share about issue 2672 (or whatever it's a dup of), I'd like to start with that issue.  If there are no violent objections, we'll go there now.  Take it away, Sergey... 
17:03:39  <garyo>        mingw cmd line? 
17:03:50  <loonycyborg>  That guy had trouble linking libraries due to inherent limit on length of command lines in windows. 
17:03:54  <jason_at_intel>       Is that not a dup of [TempFileMunge](TempFileMunge) bug? 
17:05:25  <loonycyborg>  That [TempFileMunge](TempFileMunge) thingy doesn't seem to be used for mingw at all. 
17:05:37  <jason_at_intel>       Yep 
17:05:52  <loonycyborg>  Probably because mingw gcc < 4 doesn't support the @ indirection. 
17:05:59  <jason_at_intel>       I just looked..  there is no use of TEMPFILE in the tool 
17:06:11  <jason_at_intel>       this would have to be added to the tool, so it could be used 
17:06:31  <jason_at_intel>       what does it support? 
17:06:41  <jason_at_intel>       I believe the tempfile does not have to use @ 
17:07:00  <garyo>        jason: gcc didn't used to support any kind of cmd files iirc. 
17:07:02  <loonycyborg>  What else can it do? 
17:07:35  <jason_at_intel>       does it work if you add the full command to the a batch file? 
17:07:51  <jason_at_intel>       grasping at straws here ... 
17:08:13  <garyo>        Sergey: if >=4.0 works could we just use tempfile in that case? 
17:08:36  <[GregNoel](GregNoel)>     At the risk of showing my complete lack of knowledge, the point is that the _internal_ _calls_ used by MinGW exceed the magic limit, so there's no way it can be made to work. 
17:09:07  <loonycyborg>  Probably yes. For lesser limits. There also are some in the shell iirc. 
17:09:45  <garyo>        I wonder what make would do in this same case.  Maybe we don't have to do any better than make here. 
17:09:33  *      sgk (~sgk@nat/google/x-gafuxkitacszsdsy) has joined #SCONS 
17:09:40  <sgk>  anyone still here? 
17:09:42  <jason_at_intel>       hi Steve! 
17:09:48  <garyo>        Hi Steven 
17:09:49  <[GregNoel](GregNoel)>     No, we've all left. 
17:09:52  <sgk>  sorry I'm later, got caught up debugging 
17:10:02  <sgk>  unfortunately, i still have to hike over to the shuttle 
17:10:29  <loonycyborg>  The standard practice is to build those objects into intermediate archives so command lines do not break the limit. 
17:10:41  <loonycyborg>  Perhaps scons could automate this somehow. 
17:10:56  <sgk>  (what number are we on?) 
17:10:54  <garyo>        sgk: we're talking about 2672, mingw line length limit 
17:11:17  <bdbaddog>     2672 
17:11:26  <jason_at_intel>       we jumped to 2672 
17:10:58  <sgk>  thx 
17:11:29  <garyo>        loonycyborg: seems like too much magic to me, I'd just suggest users do it explicitly as they do with make 
17:11:44  <garyo>        (i.e. just document it) 
17:12:06  <loonycyborg>  It would be nice to abstract those details. 
17:12:07  <jason_at_intel>       so steve.. do you of a way for gcc to get the command it will use from a text files? 
17:12:18  <loonycyborg>  Would help with portability. 
17:12:40  *      sgk searches for the one he thought it was a dup of 
17:12:45  <[GregNoel](GregNoel)>     Steven, Sergey was in a conversation on IRC about MinGW the other day.  At the risk of showing my complete lack of knowledge, the point is that the _internal_ _calls_ (viz. calling cppplus or the loader) used by MinGW exceed the magic line-length limit, so there's no way it can be made to work. 
17:12:46  <bdbaddog>     can you specify the file as - and feed it stdout ? 
17:12:49  <garyo>        I'd be upset if my build tool suddenly built half my objects into a temp archive. 
17:13:14  <sgk>  [http://scons.tigris.org/issues/show_bug.cgi?id=2628](http://scons.tigris.org/issues/show_bug.cgi?id=2628) 
17:13:25  <garyo>        but the portability point is a good one, I admit 
17:13:38  <sgk>  not a dup of the specific circumstance (2628 puts it in the context of batch building) 
17:13:48  <sgk>  but now that i saw 2672, i think it's the general problem 
17:14:15  <sgk>  2628 has a code snippet that wraps shared object command lines with $(TEMPFILE{} by hand 
17:14:11  <garyo>        sgk: it's different because mingw doesn't support @ file indirection, so TEMPFILE doesn't work at all. 
17:14:21  <sgk>  aha 
17:14:33  <sgk>  okay, don't mind me... :-) 
17:14:34  <loonycyborg>  It does support it starting at gcc4 
17:15:26  <jason_at_intel>       so with gcc 4.1o there is @ support 
17:15:31  <jason_at_intel>       4.1.0 
17:15:30  <garyo>        Well, 4's been out for a while now... maybe we just use TEMPFILE and hope for the best.  Short cmd lines won't notice any difference. 
17:16:23  <jason_at_intel>       I agree with gary 
17:16:51  <garyo>        anyone object? 
17:16:55  <jason_at_intel>       but we would want to make the limit around 8K not 1K as it is in [TempFile](TempFile) currently to reduce risk 
17:17:11  <[GregNoel](GregNoel)>     Is there a decision? 
17:17:13  <garyo>        good point, Jason. 
17:17:24  <sgk>  k, i'll be back in ~6-8 minutes 
17:17:27  *      sgk has quit (Quit: sgk) 
17:17:53  <garyo>        Sounds like a decision to me.  Use TEMPFILE, which will work with gcc >=4, and won't hurt short cmd lines on earlier versions. 
17:18:01  <jason_at_intel>       Add tempFile.. and make the limit it uses to 8K for the ming tool 
17:18:15  <garyo>        Sergey, what do you think? 
17:18:17  <loonycyborg>  [GregNoel](GregNoel): TEMPFILE could still help with 8K limit. 
17:19:05  <loonycyborg>  32K not so much because mingw does call ld commands that do break the limit too. 
17:19:18  <[GregNoel](GregNoel)>     loonycyborg, I'm a Unix weenie, so I don't even know what a TEMPFILE does, much less what the limits are. 
17:20:00  <jason_at_intel>       the cmd.exe has a 8K limit for stuff it passes on the Commandline 
17:20:10  <[GregNoel](GregNoel)>     ...  And I don't care. 
17:20:13  <garyo>        ok, so 2672, loonycyborg, 2.?, p? 
17:20:45  <garyo>        (Do'nt mean to sign you up unless you're OK w/ it, Sergey) 
17:20:33  <jason_at_intel>       so tempfile make a file that the exe can read to get really long commandlines 
17:21:03  <jason_at_intel>       it seem gcc has it own limit however that can break on linux 
17:21:12  <jason_at_intel>       that is why the @ option was added 
17:21:26  <jason_at_intel>       not a linux bug but a gcc one 
17:21:51  <garyo>        I suggest 2.2 p3 unless Sergey (or whoever) has time to do it for 2.1 
17:22:15  <jason_at_intel>       +1 
17:22:20  <loonycyborg>  Strictly speaking I can't do anything since I don't have commit access :P 
17:23:07  <garyo>        ok, if you make a patch I can commit it.  (Unless anyone else has a mingw setup they can test on) 
17:23:52  <garyo>        ... crickets ... 
17:24:16  <bdbaddog>     no mingw here. 
17:24:19  <garyo>        so are we done with this one? :-) 
17:24:30  <bdbaddog>     +1 on done 
17:24:31  <loonycyborg>  I have several mingw setups, so I'll look into it.. 
17:24:43  <[GregNoel](GregNoel)>     done 
17:25:00  <garyo>        great.  Sergey, reassign to me when you've got the patch. 
17:25:26  <[GregNoel](GregNoel)>     (Thanks Sergey) 
17:26:45  <loonycyborg>  Though I'm surprised that noone else here has a mingw setup. 
17:27:05  <loonycyborg>  [http://nuwen.net/mingw.html](http://nuwen.net/mingw.html) <-  that mingw distro is easy to deploy. 
17:27:32  <garyo>        loonycyborg: I should try it.  I mostly use cygwin tools on windows, but Intel compiler. 
17:27:33  <jason_at_intel>       I had one... but i have no need to use it.. I have free window compiler 
17:25:01  <[GregNoel](GregNoel)>     moving on to 2629 
17:25:02  <jason_at_intel>       2629? 
17:25:49  <garyo>        2629: defer till sgk is back online? 
17:25:59  <jason_at_intel>       +1 
17:26:18  <garyo>        2671 then 
17:26:47  *      sgk (~[sgk@67.218.110.174](mailto:sgk@67.218.110.174)) has joined #SCONS 
17:27:03  <[GregNoel](GregNoel)>     Speaking of the devil... 
17:27:06  <sgk>  hello again 
17:27:07  <garyo>        Sigh, I'll take 2671 to test and commit it.  Make it p3 though. 
17:27:31  <[GregNoel](GregNoel)>     works for me; thanks. 
17:28:13  <garyo>        So back to 2629 now that sgk is back... 
17:28:21  <[GregNoel](GregNoel)>     Back to 2629? 
17:28:37  <sgk>  k 
17:28:46  <sgk>  2.1 p1 sk is my vote 
17:28:55  <[GregNoel](GregNoel)>     done 
17:29:00  <sgk>  i should have filled in owner 
17:29:11  <garyo>        +1, thanks Steven 
17:29:11  <[GregNoel](GregNoel)>     2650? 
17:29:38  <garyo>        no prob if it's delayed.  Mark as research p4 and we'll get to it when you're ready. 
17:29:39  <jason_at_intel>       what is SEP 
17:29:45  <garyo>        Scons Enhancement Proposal 
17:29:55  <garyo>        (see the wiki) 
17:29:57  <jason_at_intel>       ahh DUH :-) 
17:29:46  <[GregNoel](GregNoel)>     done 
17:29:55  <[GregNoel](GregNoel)>     2664? 
17:30:39  <bdbaddog>     I'll take it. 
17:30:41  <sgk>  go bill 
17:30:46  <garyo>        yay 
17:31:00  <sgk>  many thnx 
17:30:55  <[GregNoel](GregNoel)>     research p3? 
17:31:25  <sgk>  research p3 feels right to me 
17:31:30  <[GregNoel](GregNoel)>     done 
17:31:37  <[GregNoel](GregNoel)>     2665? 
17:31:56  <sgk>  i guess the key question is whether we want this sort of thing to "Just Work" 
17:31:58  <garyo>        Greg: are you sure we don't escape special chars in filenames? 
17:32:24  <[GregNoel](GregNoel)>     garyo, not absolutely positive, but I believe so. 
17:32:14  <sgk>  we don't 
17:32:19  <sgk>  or rather 
17:32:29  <sgk>  we kind of do some, but not well 
17:32:53  <garyo>        ok, so it sounds invalid then (except maybe for the space one, spaces are kinda important these days) 
17:33:06  <[GregNoel](GregNoel)>     Steven has it right.  There's an escape() function defined, but it doesn't do all that much. 
17:33:33  <sgk>  the reason his file file "()" in the name was getting rebuilt all the time is because the actual file we built was something like test\(\) 
17:33:37  <sgk>  with the backslashes in the file name 
17:33:44  <sgk>  so something somewhere did try to escape those 
17:33:45  <jason_at_intel>       is that what is used in the SPAWN functions? 
17:34:15  <sgk>  i personally like the idea that all of this gets cleaned up and supported by using subprocess 
17:34:21  <sgk>  am i dreaming? 
17:34:36  <bdbaddog>     sounds like a good dream to me.. ;) 
17:34:59  <jason_at_intel>       nope.. I though we are to look at this when i visit? 
17:35:08  <garyo>        Still need quoting/escaping though in some cases I think... but keeping args as a list til the last minute is a big step in the right direction. 
17:35:10  <jason_at_intel>       see what i had done.. and see what is needed to make it work in SCOns 
17:35:21  <garyo>        +1 
17:35:34  <sgk>  so do we keep 2665 around to document the test case? 
17:35:35  <[GregNoel](GregNoel)>     The subprocess() docs say (or at least imply) that if you pass a list of operands, it quotes them if you use a shell.  I presume it's smart enough to do it correctly. 
17:35:50  <sgk>  smarter than we are, anyway... :-) 
17:36:22  <jason_at_intel>       It is... You can use the escape function with subprocess 
17:36:28  <jason_at_intel>       it will make the call fail 
17:36:35  <garyo>        either keep 2665 around or close as invalid and capture testcase elsewhere 
17:36:44  <sgk>  i had an idea about issues like this with good future test cases 
17:36:44  <jason_at_intel>       just saying from experience on this one 
17:37:07  <sgk>  what if we checked in the test case as a skipped test? 
17:37:41  <sgk>  with some message like "TODO:  issue 2661" or some such 
17:38:00  <[GregNoel](GregNoel)>     I did that for a couple of the cases I converted into deprecated since I didn't have the tools to test it. 
17:37:26  <garyo>        good idea 
17:37:57  <garyo>        the only hard part is remembering it's there, and un-skipping it when the time's right. 
17:38:01  <sgk>  they could be in a separate test/pending subdirectory 
17:38:23  <[GregNoel](GregNoel)>     sgk, that works. 
17:38:54  <sgk>  k, well let's add that to the mental toolbox of ways to handle issues 
17:39:05  <sgk>  since i suggested it, i can be the stuckee for that 
17:39:10  <garyo>        thanks! 
17:39:37  <sgk>  give me 2665, say, 2.x p4?  and I'll capture the test case 
17:39:47  <sgk>  do we have a "subprocess" or similar keyword for issues? 
17:39:48  <[GregNoel](GregNoel)>     so 2665 sk to capture test, then mark invalid? 
17:40:57  *      [GregNoel](GregNoel) is checking if there's a 'subprocess' keyword 
17:40:29  <sgk>  i can go either way 
17:40:43  <sgk>  invalid (with an explanation) if we just want to get it off the books 
17:41:08  <[GregNoel](GregNoel)>     get it off the books. 
17:41:47  <sgk>  ok by me 
17:42:06  <sgk>  I'll track down a recommended workaround and update the issue with it when i close it 
17:42:20  <sgk>  plus explain that we're checking in the test case for future 
17:42:16  <garyo>        perfect 
17:41:43  <garyo>        Don't we also have a quoting keyword or something like that? 
17:43:12  <[GregNoel](GregNoel)>     sgk, no subprocess keyword, garyo, use 'subst' 
17:44:06  <garyo>        Anyway sgk's going to close 2665 so keyword doesn't matter 
17:42:55  <garyo>        2666? 
17:43:22  <sgk>  3.0 feels right to me because of the incompatibility 
17:43:52  <sgk>  (bdbaddog:  this is an inconsistency with what's in [CacheDir](CacheDir), not what's in .sconsign) 
17:44:01  <bdbaddog>     SGK: gotcha 
17:44:04  <jason_at_intel>       so is a false rebuild once on windows that big of an issue? 
17:45:05  <jason_at_intel>       besides you have to delete the directory every so often as it just grows 
17:45:07  <sgk>  Jason_at_intel:  i can be persuaded, but if i were a user upgrading to 2.1 and the tool rebuilt everything on Windows but not Linux, I'd start to wonder 
17:45:14  <garyo>        Jason: we have treated it that way in the past. 
17:45:52  <jason_at_intel>       I am not against it... I just don't see it as a big deal 
17:46:06  <sgk>  yeah, it not being a big deal also pushes it to 3.0 for me 
17:46:07  <jason_at_intel>       Changes  to builder have similar effects 
17:46:13  <garyo>        We could always make it optional now, then flip the switch in 3.0 
17:46:50  <[GregNoel](GregNoel)>     garyo, not a bad idea, but a lot of work. 
17:47:09  <garyo>        Greg: probably right.  Just throwing it out there. 
17:46:34  <jason_at_intel>       so most people expect a small rebuild when updating SCons 
17:46:45  <sgk>  it feels like a corner case (pulling out the same generated files across platforms) that isn't burning anybody down 
17:47:16  <sgk>  more than seems worth it given the small subset of people likely affected 
17:47:18  <jason_at_intel>       A switch is always safe 
17:47:29  <garyo>        So we're agreed 3.0 p3/p4? 
17:47:36  <bdbaddog>     +1 
17:47:38  <[GregNoel](GregNoel)>     garyo +1 
17:47:44  <sgk>  +1 
17:47:49  <[GregNoel](GregNoel)>     done 
17:47:57  <[GregNoel](GregNoel)>     2667 
17:48:05  <garyo>        2667: thanks Bill! 
17:48:11  <bdbaddog>     np. 
17:48:45  <[GregNoel](GregNoel)>     2668 same? 
17:48:28  <sgk>  also thanks bill 
17:48:32  <bdbaddog>     np 
17:48:46  <jason_at_intel>       Ya Bill :-) 
17:48:56  <[GregNoel](GregNoel)>     done 
17:49:03  <[GregNoel](GregNoel)>     2670 
17:49:21  <[GregNoel](GregNoel)>     consensus invalid 
17:49:30  <sgk>  invalid, close it (off the books) and invite reopen 
17:49:35  <sgk>  (2670 that is) 
17:49:37  <jason_at_intel>       Gary hit the main point 
17:49:52  <garyo>        But sometime I want to talk about why scons has to only build . by default... some other time. 
17:50:24  <sgk>  sure 
17:49:28  <[GregNoel](GregNoel)>     2671 
17:50:25  <garyo>        2671: I'll take that, integrate the patch & test. 
17:50:34  <sgk>  cool, thnx 
17:50:32  <[GregNoel](GregNoel)>     thanks; done 
17:51:06  <[GregNoel](GregNoel)>     2672 already discussed 
17:51:16  <[GregNoel](GregNoel)>     2114 
17:52:02  <garyo>        Agree we need to reassign... but who's doing any Fortran? 
17:52:32  <[GregNoel](GregNoel)>     This looks more like user error to me 
17:53:00  <[GregNoel](GregNoel)>     It's probably that bug where a missing tool will cause actions to change. 
17:53:03  <garyo>        Greg: that's one way to look at it.  But the suffix logic is overcomplicated too, which contributes. 
17:53:34  <[GregNoel](GregNoel)>     True, but that's where anonymous builders should come in. 
17:53:51  <garyo>        I just looked at it.  The user sets FORTRANFILESUFFIXES, then in [FortranCommon](FortranCommon).py the generate function turns that into FORTRANSUFFIXES.  So if you set FORTRANFILESUFFIXES later it has no effect. 
17:54:04  <garyo>        (or sth like that) 
17:54:03  <sgk>  there's a fair amount of diagnosis in the issue already 
17:54:34  <garyo>        I think it does eventually come down to "don't do it like that" though, not an actual bug. 
17:54:45  <[GregNoel](GregNoel)>     I'll not fight; a short-term fix is fine 
17:54:23  <sgk>  how about 2.x p4 sk? 
17:54:44  <garyo>        sgk: ok by me... 
17:55:07  <[GregNoel](GregNoel)>     2.x p4 sk is fine 
17:55:16  <sgk>  done 
17:55:17  <[GregNoel](GregNoel)>     consensus? 
17:55:25  <bdbaddog>     +1 
17:55:32  <jason_at_intel>       +1 
17:55:28  <[GregNoel](GregNoel)>     2128 
17:56:08  <sgk>  2128:  2.1 p3 sk (looks pretty quick) 
17:56:17  <garyo>        thanks 
17:56:19  <[GregNoel](GregNoel)>     done; thanks 
17:56:31  <[GregNoel](GregNoel)>     2249 
17:57:16  <[GregNoel](GregNoel)>     bypass?  There's only the one comment so it doesn't abide by the "two significant comments" rule. 
17:57:30  <sgk>  defer to next time 
17:57:33  <garyo>        relook next time 
17:57:36  <[GregNoel](GregNoel)>     done 
17:57:48  <jason_at_intel>       Thanks greg 
17:57:53  <sgk>  2485:  defer also? 
17:58:01  <garyo>        still working on 2485.  It's weird. 
17:58:10  <[GregNoel](GregNoel)>     defer or reassign to p2 or p3? 
17:58:40  <garyo>        Keep as p1 so we review next time.  I should have news by then. 
17:58:46  <[GregNoel](GregNoel)>     done 
17:59:01  <[GregNoel](GregNoel)>     2521? 
17:59:16  <[GregNoel](GregNoel)>     bypass? 
17:59:34  <bdbaddog>     sure. til next time. 
17:59:35  <sgk>  defer 
17:59:40  <[GregNoel](GregNoel)>     done 
17:59:52  <[GregNoel](GregNoel)>     2575 bypass? 
18:00:02  <sgk>  sure 
18:00:30  <[GregNoel](GregNoel)>     seeing no other response, done 
18:00:36  <[GregNoel](GregNoel)>     2630 
18:00:52  <[GregNoel](GregNoel)>     2.1 p1 Steven? 
18:01:03  <sgk>  worksforme 
18:01:07  <garyo>        thanks! 
18:01:21  <[GregNoel](GregNoel)>     Is it really a regression or should it be p2? 
18:01:48  <garyo>        Can't be a regression, this never worked with batch 
18:02:07  <[GregNoel](GregNoel)>     2.1 p2 then? 
18:02:14  <garyo>        +1 
18:02:20  <[GregNoel](GregNoel)>     done 
18:02:32  <[GregNoel](GregNoel)>     That's it for today; good work. 
18:02:42  <[GregNoel](GregNoel)>     I didn't think we were going to finish them all... 
18:02:44  <garyo>        agreed, thanks all 
18:02:49  <sgk>  good stuff 
18:02:55  <garyo>        We started slow, I was worried too :-) 
18:03:17  <garyo>        so who wants to talk about dvcs? 
18:03:18  <sgk>  bad traffic today, so i'll be on for awhile 
18:03:25  <bdbaddog>     +1 dvcs 
18:03:31  <sgk>  obviously people are free to go, but i'll stay and talk dvcs as long as i can 
18:04:03  <sgk>  bdbaddog:  thanks for weighing in on the email thread, the HOWTO list is a good start 
18:04:01  <garyo>        I'm in the middle of switching my company to git so I'm designing workflows, repo layouts, branch models etc. 
18:04:14  <sgk>  garyo:  msysgit on Windows? 
18:04:33  <garyo>        Yes, though a couple like tortoisegit. 
18:04:50  <garyo>        But we're going with hg, right? 
18:05:12  <garyo>        (or am I jumping the gun?) 
18:05:17  <jason_at_intel>       I really wish we are not going with GIT 
18:05:32  <jason_at_intel>       HG or bzr are more cross platform friendly 
18:05:45  <jason_at_intel>       and work with SVN 
18:05:58  <garyo>        I thought we'd all-but-decided hg, since it's python and is at least reasonable 
18:05:39  <sgk>  nah, it's time to just pick and make it happen and work the consequences 
18:06:07  <garyo>        sgk: agreed.  Pick one. 
18:06:04  <sgk>  fwiw, chrome team hasn't gotten msysgit to the point where they can really rely on it 
18:06:23  <sgk>  but i think the issues are more that it doesn't work w/all the git-svn stuff, and they still have to use svn for public 
18:06:49  <garyo>        sgk: hmm.  We are going to cut over hard at work, and we are NOT using git-svn for the cutover (custom scripts) 
18:07:05  <[GregNoel](GregNoel)>     Sorry, I was called away for a bit.  I like Hg as it's scriptable in Python, but otherwise I don't care. 
18:07:14  <sgk>  garyo:  you've experimented w/hg, yes? 
18:07:25  <sgk>  (but not bzr) 
18:07:26  <garyo>        sgk: yes, it was reasonable. 
18:07:27  <jason_at_intel>       the main reason for DVCS is for allowing people and easy way to clone and share... vs submit a patch.. right? 
18:07:45  <sgk>  that's a key driver for me 
18:07:58  <garyo>        jason: yes, and local topic branches and better merging and so on. 
18:08:10  <sgk>  i've been switching back and forth between hg front-ending svn and svn, and dvcs is definitely more convenient 
18:08:23  <sgk>  okay, let's go with hg 
18:08:36  <sgk>  we have more experience amongst us with it thant bzar 
18:08:45  <garyo>        sgk: agreed.  It's python, it's reasonable. 
18:08:59  <jason_at_intel>       That is fine with me.. the BZR has better SVN mixing ... but in the end we are dropping SVN 
18:09:17  <sgk>  yeah, hopefully 
18:09:32  <garyo>        I think it's easier in the long run 
18:08:43  <[GregNoel](GregNoel)>     Sounds good.  Where do we want to start? 
18:09:41  <garyo>        After 2.1 is out maybe? 
18:10:04  <garyo>        Or do you guys want to do it sooner? 
18:10:25  <sgk>  let's get 2.1 out and tackle it right after 
18:10:36  <sgk>  russel's argument for that timing was good 
18:09:58  <bdbaddog>     o.k. so google code hosting, bitbucket.org hosting, sourceforge, other? 
18:09:58  <sgk>  so far i've been finding the hg / svn interaction okay for normal work 
18:10:20  <garyo>        bdbaddog: are those the main hg choices? 
18:10:27  <jason_at_intel>       so is the plan to have three different sites? one for DVCS, one for downloads, and one for bug tracking? 
18:10:36  <bdbaddog>     if we do it sooner for 2.1, that'll give us some time to get used to it before we release, and then have to deal with bugs in that stream. 
18:10:40  <sgk>  gives us a little time to plan, too 
18:10:53  <jason_at_intel>       or go with bit bucket and more stuff all there 
18:11:02  <garyo>        jason: don't forget the main scons.org site too ;-) 
18:11:15  <sgk>  jason_at_intel:  i think three sites is what we're looking at now 
18:11:24  <bdbaddog>     I don't see any reason to move all of them at the same time (bug, download, sources) 
18:11:34  <jason_at_intel>       yep .. so four sites total 
18:11:42  <garyo>        bdbaddog: sounds like we should investigate the alternatives for hosting.  And I definitely don't want to move the other stuff at the same time. 
18:11:45  <sgk>  but we can at least decide now with an eye towards what looks like reasonable bug tracking 
18:12:14  <jason_at_intel>       Seems good... I just like to have a fewer sites long term 
18:11:35  <[GregNoel](GregNoel)>     Gary, is the Hg server by-demand or persistent?  Could we run it on scons.org? 
18:11:59  <sgk>  [GregNoel](GregNoel):  ooh, good point 
18:12:26  <garyo>        Greg: to run it decently it needs to be persistent.  I don't think we can do it on scons.org.  Also the big hosts give some eye candy around the repo which can be helpful. 
18:12:42  <bdbaddog>     Yeah -100 on running it ourselves. 
18:12:57  <bdbaddog>     backups, operational issues not worth handling. 
18:13:15  <sgk>  good point 
18:12:15  <bdbaddog>     I'd sugguest just talking about DVCS, get that done, and then talk about the rest? 
18:12:21  <sgk>  one of the things i like most about hg so far is being able to pull from a remote repository on demand over ssh 
18:13:26  <garyo>        Android's hosted on google and seems OK, but let's do a little poking around before we choose. 
18:13:52  <sgk>  we already moved away from sourceforge once because of the bug tracking 
18:14:01  <sgk>  i'd probably veto going back unless it's improved significantly 
18:14:21  <garyo>        I remember the SF switch well :-/ 
18:14:37  <[GregNoel](GregNoel)>     <shudder> so do I 
18:14:03  <bdbaddog>     only caveat on google (and maybe others) is that there's a limited # of licenses, you can't roll your own. 
18:14:31  <sgk>  licenses for...? 
18:14:40  <sgk>  i.e. number of branches you can host? 
18:14:53  <garyo>        So sounds like we investigate google, bitbucket... and anything else? 
18:15:01  <bdbaddog>     source code licenses (GPL, MIT,etc..) 
18:15:35  <sgk>  we're MIT, so i'm pretty sure we're okay 
18:15:42  <bdbaddog>     k. 
18:15:46  <bdbaddog>     MIT's there. 99% sure. 
18:15:56  <loonycyborg>  googlecode supports hg FWIW 
18:16:13  <sgk>  any others to contemplate besides code.google.com and bitbucket? 
18:16:25  <loonycyborg>  Sourceforge :P 
18:16:36  <garyo>        Those were the only ones I recognized at [http://mercurial.selenic.com/wiki/MercurialHosting](http://mercurial.selenic.com/wiki/MercurialHosting) 
18:17:01  <garyo>        ... that seemed suitable for us, I mean. 
18:17:10  <sgk>  snark aside, has sourceforge gotten more reasonable lately (especially the bug tracker)? 
18:17:30  <bdbaddog>     nope. still junk. 
18:17:39  <[GregNoel](GregNoel)>     Not that I've seen.  I follow a project that still uses it and it's horrible. 
18:17:45  <loonycyborg>  FRS was improved somewhat. 
18:18:19  <loonycyborg>  FRS seems to be the only worthwhile thing about sourceforge. 
18:18:19  <jason_at_intel>       I agree... I like bitbucket more myself 
18:18:21  <bdbaddog>     so web based pull requests and forking are nice to have with DVCS's. 
18:18:35  <bdbaddog>     I've been using bitbucket for a personal project for a bit, seems o.k. to me. 
18:19:06  <jason_at_intel>       it seems to have a lot of stuff 
18:17:47  <sgk>  if they're not a strong contender, then let's not waste time evaluating them 
18:17:56  <bdbaddog>     yup. google or bitbucket. 
18:18:17  <garyo>        ok.  Post any findings to the dev ML and we'll regroup and decide. 
18:18:30  <sgk>  Mailing LIst, wiki page, or both? 
18:18:47  <bdbaddog>     wiki - yes 
18:19:02  <[GregNoel](GregNoel)>     sgk, we'll need a summary eventually, so should start now. 
18:19:19  <garyo>        Greg: I was going to disagree but that's a good point. 
18:19:24  <garyo>        So +1 on wiki. 
18:19:27  <sgk>  okay, wiki it is 
18:19:31  <sgk>  any volunteers to start the page?  I will unless someone else is eager 
18:19:55  <garyo>        Once it's started, don't forget to subscribe to it, everyone. 
18:20:02  <[GregNoel](GregNoel)>     ... but still converse on dev list (or release list?) 
18:20:02  <sgk>  right 
18:20:35  <sgk>  i think we can play that a little by ear 
18:20:47  <sgk>  dev list for kicking around ideas 
18:21:02  <sgk>  wiki page for final decisions and opinions that you want made part of the public record 
18:21:06  <[GregNoel](GregNoel)>     play by ear makes sense. 
18:21:30  <garyo>        Has Russel(?) converted SCons to an hg repo?  Or did someone else? 
18:21:47  <sgk>  i think he has both a bzr and hg repo somewhere? 
18:22:07  <garyo>        That's good news, means our cutover may be smooth. 
18:22:18  <sgk>  i know he's a bug fan of bzr and Launchpad 
18:22:18  <sgk>  big 
18:22:28  <garyo>        yep 
18:22:33  <[GregNoel](GregNoel)>     or even a big bug fan... 
18:22:54  <jason_at_intel>       I believe there is a BZR and HG repro out there 
18:23:00  <sgk>  i'll probably start two pages, one to hold brainstorming on the task list (and sign up volunteers) 
18:23:10  <sgk>  and one to discuss pros + cons of code.google.com and bitbucket 
18:23:24  <garyo>        That sounds great 
18:23:37  <[GregNoel](GregNoel)>     sgk, you can use /Discussion pages for some of that. 
18:23:50  <sgk>  [GregNoel](GregNoel):  good point 
18:23:35  <garyo>        ok, I think I'm going to sign off now & get some sleep.  This is all good progress & thought. 
18:23:36  <sgk>  (<1 minute to shuttle end) 
18:24:03  <sgk>  okay, gotta go -- thanks everyone, lot of good work tonight 
18:24:07  <garyo>        g'night 
18:24:12  <jason_at_intel>       well good night all.. till next time 
18:24:16  <[GregNoel](GregNoel)>     Looks like it's over tonight; g'night all. 
18:24:20  *      sgk (~[sgk@67.218.110.174](mailto:sgk@67.218.110.174)) has left #SCONS 
18:24:26  *      garyo (~[garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com](mailto:garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)) has left #SCONS 
18:24:33  *      jason_at_intel has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.6.6/20100625231939]) 
18:44:15  *      loonycyborg has quit (Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz) 
21:13:39  *      bdbaddog has quit (Read error: Connection reset by peer) 

Updated