IrcLog2010 08 03

William Deegan edited this page Jan 14, 2016 · 2 revisions
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) 

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.