116:41:49 * jason_at_intel (~chatzilla@131.sub-75-207-82.myvzw.com) has joined #SCONS 216:45:32 * garyo (~garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS 317:00:22 * GregNoel has arrived and is setting up 417:01:03 * bdbaddog (~bdeegan@adsl-71-131-10-196.dsl.sntc01.pacbell.net) has joined #SCONS 517:01:57 <GregNoel> I don't see Steven, but it looks like a pretty full house. Sergey, are you there? 617:02:10 <loonycyborg> Yes. 717:02:14 <garyo> Hi Sergey! 817:02:23 <loonycyborg> Hello. 917:02:23 <GregNoel> Are we ready to start? 1017:02:40 <garyo> I think so 1117:02:41 <jason_at_intel> I am ready 1217:02:45 <jason_at_intel> are we going to wait for steven? 1317:02:56 <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... 1417:03:39 <garyo> mingw cmd line? 1517:03:50 <loonycyborg> That guy had trouble linking libraries due to inherent limit on length of command lines in windows. 1617:03:54 <jason_at_intel> Is that not a dup of TempFileMunge bug? 1717:05:25 <loonycyborg> That TempFileMunge thingy doesn't seem to be used for mingw at all. 1817:05:37 <jason_at_intel> Yep 1917:05:52 <loonycyborg> Probably because mingw gcc < 4 doesn't support the @ indirection. 2017:05:59 <jason_at_intel> I just looked.. there is no use of TEMPFILE in the tool 2117:06:11 <jason_at_intel> this would have to be added to the tool, so it could be used 2217:06:31 <jason_at_intel> what does it support? 2317:06:41 <jason_at_intel> I believe the tempfile does not have to use @ 2417:07:00 <garyo> jason: gcc didn't used to support any kind of cmd files iirc. 2517:07:02 <loonycyborg> What else can it do? 2617:07:35 <jason_at_intel> does it work if you add the full command to the a batch file? 2717:07:51 <jason_at_intel> grasping at straws here ... 2817:08:13 <garyo> Sergey: if >=4.0 works could we just use tempfile in that case? 2917:08:36 <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. 3017:09:07 <loonycyborg> Probably yes. For lesser limits. There also are some in the shell iirc. 3117: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. 3217:09:33 * sgk (~sgk@nat/google/x-gafuxkitacszsdsy) has joined #SCONS 3317:09:40 <sgk> anyone still here? 3417:09:42 <jason_at_intel> hi Steve! 3517:09:48 <garyo> Hi Steven 3617:09:49 <GregNoel> No, we've all left. 3717:09:52 <sgk> sorry I'm later, got caught up debugging 3817:10:02 <sgk> unfortunately, i still have to hike over to the shuttle 3917:10:29 <loonycyborg> The standard practice is to build those objects into intermediate archives so command lines do not break the limit. 4017:10:41 <loonycyborg> Perhaps scons could automate this somehow. 4117:10:56 <sgk> (what number are we on?) 4217:10:54 <garyo> sgk: we're talking about 2672, mingw line length limit 4317:11:17 <bdbaddog> 2672 4417:11:26 <jason_at_intel> we jumped to 2672 4517:10:58 <sgk> thx 4617:11:29 <garyo> loonycyborg: seems like too much magic to me, I'd just suggest users do it explicitly as they do with make 4717:11:44 <garyo> (i.e. just document it) 4817:12:06 <loonycyborg> It would be nice to abstract those details. 4917: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? 5017:12:18 <loonycyborg> Would help with portability. 5117:12:40 * sgk searches for the one he thought it was a dup of 5217:12:45 <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. 5317:12:46 <bdbaddog> can you specify the file as - and feed it stdout ? 5417:12:49 <garyo> I'd be upset if my build tool suddenly built half my objects into a temp archive. 5517:13:14 <sgk> http://scons.tigris.org/issues/show_bug.cgi?id=2628 5617:13:25 <garyo> but the portability point is a good one, I admit 5717:13:38 <sgk> not a dup of the specific circumstance (2628 puts it in the context of batch building) 5817:13:48 <sgk> but now that i saw 2672, i think it's the general problem 5917:14:15 <sgk> 2628 has a code snippet that wraps shared object command lines with $(TEMPFILE{} by hand 6017:14:11 <garyo> sgk: it's different because mingw doesn't support @ file indirection, so TEMPFILE doesn't work at all. 6117:14:21 <sgk> aha 6217:14:33 <sgk> okay, don't mind me... :-) 6317:14:34 <loonycyborg> It does support it starting at gcc4 6417:15:26 <jason_at_intel> so with gcc 4.1o there is @ support 6517:15:31 <jason_at_intel> 4.1.0 6617: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. 6717:16:23 <jason_at_intel> I agree with gary 6817:16:51 <garyo> anyone object? 6917:16:55 <jason_at_intel> but we would want to make the limit around 8K not 1K as it is in TempFile currently to reduce risk 7017:17:11 <GregNoel> Is there a decision? 7117:17:13 <garyo> good point, Jason. 7217:17:24 <sgk> k, i'll be back in ~6-8 minutes 7317:17:27 * sgk has quit (Quit: sgk) 7417: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. 7517:18:01 <jason_at_intel> Add tempFile.. and make the limit it uses to 8K for the ming tool 7617:18:15 <garyo> Sergey, what do you think? 7717:18:17 <loonycyborg> GregNoel: TEMPFILE could still help with 8K limit. 7817:19:05 <loonycyborg> 32K not so much because mingw does call ld commands that do break the limit too. 7917:19:18 <GregNoel> loonycyborg, I'm a Unix weenie, so I don't even know what a TEMPFILE does, much less what the limits are. 8017:20:00 <jason_at_intel> the cmd.exe has a 8K limit for stuff it passes on the Commandline 8117:20:10 <GregNoel> ... And I don't care. 8217:20:13 <garyo> ok, so 2672, loonycyborg, 2.?, p? 8317:20:45 <garyo> (Do'nt mean to sign you up unless you're OK w/ it, Sergey) 8417:20:33 <jason_at_intel> so tempfile make a file that the exe can read to get really long commandlines 8517:21:03 <jason_at_intel> it seem gcc has it own limit however that can break on linux 8617:21:12 <jason_at_intel> that is why the @ option was added 8717:21:26 <jason_at_intel> not a linux bug but a gcc one 8817:21:51 <garyo> I suggest 2.2 p3 unless Sergey (or whoever) has time to do it for 2.1 8917:22:15 <jason_at_intel> +1 9017:22:20 <loonycyborg> Strictly speaking I can't do anything since I don't have commit access :P 9117:23:07 <garyo> ok, if you make a patch I can commit it. (Unless anyone else has a mingw setup they can test on) 9217:23:52 <garyo> ... crickets ... 9317:24:16 <bdbaddog> no mingw here. 9417:24:19 <garyo> so are we done with this one? :-) 9517:24:30 <bdbaddog> +1 on done 9617:24:31 <loonycyborg> I have several mingw setups, so I'll look into it.. 9717:24:43 <GregNoel> done 9817:25:00 <garyo> great. Sergey, reassign to me when you've got the patch. 9917:25:26 <GregNoel> (Thanks Sergey) 10017:26:45 <loonycyborg> Though I'm surprised that noone else here has a mingw setup. 10117:27:05 <loonycyborg> http://nuwen.net/mingw.html <- that mingw distro is easy to deploy. 10217:27:32 <garyo> loonycyborg: I should try it. I mostly use cygwin tools on windows, but Intel compiler. 10317:27:33 <jason_at_intel> I had one... but i have no need to use it.. I have free window compiler 10417:25:01 <GregNoel> moving on to 2629 10517:25:02 <jason_at_intel> 2629? 10617:25:49 <garyo> 2629: defer till sgk is back online? 10717:25:59 <jason_at_intel> +1 10817:26:18 <garyo> 2671 then 10917:26:47 * sgk (~sgk@67.218.110.174) has joined #SCONS 11017:27:03 <GregNoel> Speaking of the devil... 11117:27:06 <sgk> hello again 11217:27:07 <garyo> Sigh, I'll take 2671 to test and commit it. Make it p3 though. 11317:27:31 <GregNoel> works for me; thanks. 11417:28:13 <garyo> So back to 2629 now that sgk is back... 11517:28:21 <GregNoel> Back to 2629? 11617:28:37 <sgk> k 11717:28:46 <sgk> 2.1 p1 sk is my vote 11817:28:55 <GregNoel> done 11917:29:00 <sgk> i should have filled in owner 12017:29:11 <garyo> +1, thanks Steven 12117:29:11 <GregNoel> 2650? 12217:29:38 <garyo> no prob if it's delayed. Mark as research p4 and we'll get to it when you're ready. 12317:29:39 <jason_at_intel> what is SEP 12417:29:45 <garyo> Scons Enhancement Proposal 12517:29:55 <garyo> (see the wiki) 12617:29:57 <jason_at_intel> ahh DUH :-) 12717:29:46 <GregNoel> done 12817:29:55 <GregNoel> 2664? 12917:30:39 <bdbaddog> I'll take it. 13017:30:41 <sgk> go bill 13117:30:46 <garyo> yay 13217:31:00 <sgk> many thnx 13317:30:55 <GregNoel> research p3? 13417:31:25 <sgk> research p3 feels right to me 13517:31:30 <GregNoel> done 13617:31:37 <GregNoel> 2665? 13717:31:56 <sgk> i guess the key question is whether we want this sort of thing to "Just Work" 13817:31:58 <garyo> Greg: are you sure we don't escape special chars in filenames? 13917:32:24 <GregNoel> garyo, not absolutely positive, but I believe so. 14017:32:14 <sgk> we don't 14117:32:19 <sgk> or rather 14217:32:29 <sgk> we kind of do some, but not well 14317:32:53 <garyo> ok, so it sounds invalid then (except maybe for the space one, spaces are kinda important these days) 14417:33:06 <GregNoel> Steven has it right. There's an escape() function defined, but it doesn't do all that much. 14517: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\(\) 14617:33:37 <sgk> with the backslashes in the file name 14717:33:44 <sgk> so something somewhere did try to escape those 14817:33:45 <jason_at_intel> is that what is used in the SPAWN functions? 14917:34:15 <sgk> i personally like the idea that all of this gets cleaned up and supported by using subprocess 15017:34:21 <sgk> am i dreaming? 15117:34:36 <bdbaddog> sounds like a good dream to me.. ;) 15217:34:59 <jason_at_intel> nope.. I though we are to look at this when i visit? 15317: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. 15417:35:10 <jason_at_intel> see what i had done.. and see what is needed to make it work in SCOns 15517:35:21 <garyo> +1 15617:35:34 <sgk> so do we keep 2665 around to document the test case? 15717:35:35 <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. 15817:35:50 <sgk> smarter than we are, anyway... :-) 15917:36:22 <jason_at_intel> It is... You can use the escape function with subprocess 16017:36:28 <jason_at_intel> it will make the call fail 16117:36:35 <garyo> either keep 2665 around or close as invalid and capture testcase elsewhere 16217:36:44 <sgk> i had an idea about issues like this with good future test cases 16317:36:44 <jason_at_intel> just saying from experience on this one 16417:37:07 <sgk> what if we checked in the test case as a skipped test? 16517:37:41 <sgk> with some message like "TODO: issue 2661" or some such 16617:38:00 <GregNoel> I did that for a couple of the cases I converted into deprecated since I didn't have the tools to test it. 16717:37:26 <garyo> good idea 16817:37:57 <garyo> the only hard part is remembering it's there, and un-skipping it when the time's right. 16917:38:01 <sgk> they could be in a separate test/pending subdirectory 17017:38:23 <GregNoel> sgk, that works. 17117:38:54 <sgk> k, well let's add that to the mental toolbox of ways to handle issues 17217:39:05 <sgk> since i suggested it, i can be the stuckee for that 17317:39:10 <garyo> thanks! 17417:39:37 <sgk> give me 2665, say, 2.x p4? and I'll capture the test case 17517:39:47 <sgk> do we have a "subprocess" or similar keyword for issues? 17617:39:48 <GregNoel> so 2665 sk to capture test, then mark invalid? 17717:40:57 * GregNoel is checking if there's a 'subprocess' keyword 17817:40:29 <sgk> i can go either way 17917:40:43 <sgk> invalid (with an explanation) if we just want to get it off the books 18017:41:08 <GregNoel> get it off the books. 18117:41:47 <sgk> ok by me 18217:42:06 <sgk> I'll track down a recommended workaround and update the issue with it when i close it 18317:42:20 <sgk> plus explain that we're checking in the test case for future 18417:42:16 <garyo> perfect 18517:41:43 <garyo> Don't we also have a quoting keyword or something like that? 18617:43:12 <GregNoel> sgk, no subprocess keyword, garyo, use 'subst' 18717:44:06 <garyo> Anyway sgk's going to close 2665 so keyword doesn't matter 18817:42:55 <garyo> 2666? 18917:43:22 <sgk> 3.0 feels right to me because of the incompatibility 19017:43:52 <sgk> (bdbaddog: this is an inconsistency with what's in CacheDir, not what's in .sconsign) 19117:44:01 <bdbaddog> SGK: gotcha 19217:44:04 <jason_at_intel> so is a false rebuild once on windows that big of an issue? 19317:45:05 <jason_at_intel> besides you have to delete the directory every so often as it just grows 19417: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 19517:45:14 <garyo> Jason: we have treated it that way in the past. 19617:45:52 <jason_at_intel> I am not against it... I just don't see it as a big deal 19717:46:06 <sgk> yeah, it not being a big deal also pushes it to 3.0 for me 19817:46:07 <jason_at_intel> Changes to builder have similar effects 19917:46:13 <garyo> We could always make it optional now, then flip the switch in 3.0 20017:46:50 <GregNoel> garyo, not a bad idea, but a lot of work. 20117:47:09 <garyo> Greg: probably right. Just throwing it out there. 20217:46:34 <jason_at_intel> so most people expect a small rebuild when updating SCons 20317:46:45 <sgk> it feels like a corner case (pulling out the same generated files across platforms) that isn't burning anybody down 20417:47:16 <sgk> more than seems worth it given the small subset of people likely affected 20517:47:18 <jason_at_intel> A switch is always safe 20617:47:29 <garyo> So we're agreed 3.0 p3/p4? 20717:47:36 <bdbaddog> +1 20817:47:38 <GregNoel> garyo +1 20917:47:44 <sgk> +1 21017:47:49 <GregNoel> done 21117:47:57 <GregNoel> 2667 21217:48:05 <garyo> 2667: thanks Bill! 21317:48:11 <bdbaddog> np. 21417:48:45 <GregNoel> 2668 same? 21517:48:28 <sgk> also thanks bill 21617:48:32 <bdbaddog> np 21717:48:46 <jason_at_intel> Ya Bill :-) 21817:48:56 <GregNoel> done 21917:49:03 <GregNoel> 2670 22017:49:21 <GregNoel> consensus invalid 22117:49:30 <sgk> invalid, close it (off the books) and invite reopen 22217:49:35 <sgk> (2670 that is) 22317:49:37 <jason_at_intel> Gary hit the main point 22417:49:52 <garyo> But sometime I want to talk about why scons has to only build . by default... some other time. 22517:50:24 <sgk> sure 22617:49:28 <GregNoel> 2671 22717:50:25 <garyo> 2671: I'll take that, integrate the patch & test. 22817:50:34 <sgk> cool, thnx 22917:50:32 <GregNoel> thanks; done 23017:51:06 <GregNoel> 2672 already discussed 23117:51:16 <GregNoel> 2114 23217:52:02 <garyo> Agree we need to reassign... but who's doing any Fortran? 23317:52:32 <GregNoel> This looks more like user error to me 23417:53:00 <GregNoel> It's probably that bug where a missing tool will cause actions to change. 23517:53:03 <garyo> Greg: that's one way to look at it. But the suffix logic is overcomplicated too, which contributes. 23617:53:34 <GregNoel> True, but that's where anonymous builders should come in. 23717:53:51 <garyo> I just looked at it. The user sets FORTRANFILESUFFIXES, then in FortranCommon.py the generate function turns that into FORTRANSUFFIXES. So if you set FORTRANFILESUFFIXES later it has no effect. 23817:54:04 <garyo> (or sth like that) 23917:54:03 <sgk> there's a fair amount of diagnosis in the issue already 24017:54:34 <garyo> I think it does eventually come down to "don't do it like that" though, not an actual bug. 24117:54:45 <GregNoel> I'll not fight; a short-term fix is fine 24217:54:23 <sgk> how about 2.x p4 sk? 24317:54:44 <garyo> sgk: ok by me... 24417:55:07 <GregNoel> 2.x p4 sk is fine 24517:55:16 <sgk> done 24617:55:17 <GregNoel> consensus? 24717:55:25 <bdbaddog> +1 24817:55:32 <jason_at_intel> +1 24917:55:28 <GregNoel> 2128 25017:56:08 <sgk> 2128: 2.1 p3 sk (looks pretty quick) 25117:56:17 <garyo> thanks 25217:56:19 <GregNoel> done; thanks 25317:56:31 <GregNoel> 2249 25417:57:16 <GregNoel> bypass? There's only the one comment so it doesn't abide by the "two significant comments" rule. 25517:57:30 <sgk> defer to next time 25617:57:33 <garyo> relook next time 25717:57:36 <GregNoel> done 25817:57:48 <jason_at_intel> Thanks greg 25917:57:53 <sgk> 2485: defer also? 26017:58:01 <garyo> still working on 2485. It's weird. 26117:58:10 <GregNoel> defer or reassign to p2 or p3? 26217:58:40 <garyo> Keep as p1 so we review next time. I should have news by then. 26317:58:46 <GregNoel> done 26417:59:01 <GregNoel> 2521? 26517:59:16 <GregNoel> bypass? 26617:59:34 <bdbaddog> sure. til next time. 26717:59:35 <sgk> defer 26817:59:40 <GregNoel> done 26917:59:52 <GregNoel> 2575 bypass? 27018:00:02 <sgk> sure 27118:00:30 <GregNoel> seeing no other response, done 27218:00:36 <GregNoel> 2630 27318:00:52 <GregNoel> 2.1 p1 Steven? 27418:01:03 <sgk> worksforme 27518:01:07 <garyo> thanks! 27618:01:21 <GregNoel> Is it really a regression or should it be p2? 27718:01:48 <garyo> Can't be a regression, this never worked with batch 27818:02:07 <GregNoel> 2.1 p2 then? 27918:02:14 <garyo> +1 28018:02:20 <GregNoel> done 28118:02:32 <GregNoel> That's it for today; good work. 28218:02:42 <GregNoel> I didn't think we were going to finish them all... 28318:02:44 <garyo> agreed, thanks all 28418:02:49 <sgk> good stuff 28518:02:55 <garyo> We started slow, I was worried too :-) 28618:03:17 <garyo> so who wants to talk about dvcs? 28718:03:18 <sgk> bad traffic today, so i'll be on for awhile 28818:03:25 <bdbaddog> +1 dvcs 28918:03:31 <sgk> obviously people are free to go, but i'll stay and talk dvcs as long as i can 29018:04:03 <sgk> bdbaddog: thanks for weighing in on the email thread, the HOWTO list is a good start 29118:04:01 <garyo> I'm in the middle of switching my company to git so I'm designing workflows, repo layouts, branch models etc. 29218:04:14 <sgk> garyo: msysgit on Windows? 29318:04:33 <garyo> Yes, though a couple like tortoisegit. 29418:04:50 <garyo> But we're going with hg, right? 29518:05:12 <garyo> (or am I jumping the gun?) 29618:05:17 <jason_at_intel> I really wish we are not going with GIT 29718:05:32 <jason_at_intel> HG or bzr are more cross platform friendly 29818:05:45 <jason_at_intel> and work with SVN 29918:05:58 <garyo> I thought we'd all-but-decided hg, since it's python and is at least reasonable 30018:05:39 <sgk> nah, it's time to just pick and make it happen and work the consequences 30118:06:07 <garyo> sgk: agreed. Pick one. 30218:06:04 <sgk> fwiw, chrome team hasn't gotten msysgit to the point where they can really rely on it 30318: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 30418: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) 30518:07:05 <GregNoel> Sorry, I was called away for a bit. I like Hg as it's scriptable in Python, but otherwise I don't care. 30618:07:14 <sgk> garyo: you've experimented w/hg, yes? 30718:07:25 <sgk> (but not bzr) 30818:07:26 <garyo> sgk: yes, it was reasonable. 30918: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? 31018:07:45 <sgk> that's a key driver for me 31118:07:58 <garyo> jason: yes, and local topic branches and better merging and so on. 31218:08:10 <sgk> i've been switching back and forth between hg front-ending svn and svn, and dvcs is definitely more convenient 31318:08:23 <sgk> okay, let's go with hg 31418:08:36 <sgk> we have more experience amongst us with it thant bzar 31518:08:45 <garyo> sgk: agreed. It's python, it's reasonable. 31618:08:59 <jason_at_intel> That is fine with me.. the BZR has better SVN mixing ... but in the end we are dropping SVN 31718:09:17 <sgk> yeah, hopefully 31818:09:32 <garyo> I think it's easier in the long run 31918:08:43 <GregNoel> Sounds good. Where do we want to start? 32018:09:41 <garyo> After 2.1 is out maybe? 32118:10:04 <garyo> Or do you guys want to do it sooner? 32218:10:25 <sgk> let's get 2.1 out and tackle it right after 32318:10:36 <sgk> russel's argument for that timing was good 32418:09:58 <bdbaddog> o.k. so google code hosting, bitbucket.org hosting, sourceforge, other? 32518:09:58 <sgk> so far i've been finding the hg / svn interaction okay for normal work 32618:10:20 <garyo> bdbaddog: are those the main hg choices? 32718: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? 32818: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. 32918:10:40 <sgk> gives us a little time to plan, too 33018:10:53 <jason_at_intel> or go with bit bucket and more stuff all there 33118:11:02 <garyo> jason: don't forget the main scons.org site too ;-) 33218:11:15 <sgk> jason_at_intel: i think three sites is what we're looking at now 33318:11:24 <bdbaddog> I don't see any reason to move all of them at the same time (bug, download, sources) 33418:11:34 <jason_at_intel> yep .. so four sites total 33518: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. 33618:11:45 <sgk> but we can at least decide now with an eye towards what looks like reasonable bug tracking 33718:12:14 <jason_at_intel> Seems good... I just like to have a fewer sites long term 33818:11:35 <GregNoel> Gary, is the Hg server by-demand or persistent? Could we run it on scons.org? 33918:11:59 <sgk> GregNoel: ooh, good point 34018: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. 34118:12:42 <bdbaddog> Yeah -100 on running it ourselves. 34218:12:57 <bdbaddog> backups, operational issues not worth handling. 34318:13:15 <sgk> good point 34418:12:15 <bdbaddog> I'd sugguest just talking about DVCS, get that done, and then talk about the rest? 34518: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 34618:13:26 <garyo> Android's hosted on google and seems OK, but let's do a little poking around before we choose. 34718:13:52 <sgk> we already moved away from sourceforge once because of the bug tracking 34818:14:01 <sgk> i'd probably veto going back unless it's improved significantly 34918:14:21 <garyo> I remember the SF switch well :-/ 35018:14:37 <GregNoel> <shudder> so do I 35118:14:03 <bdbaddog> only caveat on google (and maybe others) is that there's a limited # of licenses, you can't roll your own. 35218:14:31 <sgk> licenses for...? 35318:14:40 <sgk> i.e. number of branches you can host? 35418:14:53 <garyo> So sounds like we investigate google, bitbucket... and anything else? 35518:15:01 <bdbaddog> source code licenses (GPL, MIT,etc..) 35618:15:35 <sgk> we're MIT, so i'm pretty sure we're okay 35718:15:42 <bdbaddog> k. 35818:15:46 <bdbaddog> MIT's there. 99% sure. 35918:15:56 <loonycyborg> googlecode supports hg FWIW 36018:16:13 <sgk> any others to contemplate besides code.google.com and bitbucket? 36118:16:25 <loonycyborg> Sourceforge :P 36218:16:36 <garyo> Those were the only ones I recognized at http://mercurial.selenic.com/wiki/MercurialHosting 36318:17:01 <garyo> ... that seemed suitable for us, I mean. 36418:17:10 <sgk> snark aside, has sourceforge gotten more reasonable lately (especially the bug tracker)? 36518:17:30 <bdbaddog> nope. still junk. 36618:17:39 <GregNoel> Not that I've seen. I follow a project that still uses it and it's horrible. 36718:17:45 <loonycyborg> FRS was improved somewhat. 36818:18:19 <loonycyborg> FRS seems to be the only worthwhile thing about sourceforge. 36918:18:19 <jason_at_intel> I agree... I like bitbucket more myself 37018:18:21 <bdbaddog> so web based pull requests and forking are nice to have with DVCS's. 37118:18:35 <bdbaddog> I've been using bitbucket for a personal project for a bit, seems o.k. to me. 37218:19:06 <jason_at_intel> it seems to have a lot of stuff 37318:17:47 <sgk> if they're not a strong contender, then let's not waste time evaluating them 37418:17:56 <bdbaddog> yup. google or bitbucket. 37518:18:17 <garyo> ok. Post any findings to the dev ML and we'll regroup and decide. 37618:18:30 <sgk> Mailing LIst, wiki page, or both? 37718:18:47 <bdbaddog> wiki - yes 37818:19:02 <GregNoel> sgk, we'll need a summary eventually, so should start now. 37918:19:19 <garyo> Greg: I was going to disagree but that's a good point. 38018:19:24 <garyo> So +1 on wiki. 38118:19:27 <sgk> okay, wiki it is 38218:19:31 <sgk> any volunteers to start the page? I will unless someone else is eager 38318:19:55 <garyo> Once it's started, don't forget to subscribe to it, everyone. 38418:20:02 <GregNoel> ... but still converse on dev list (or release list?) 38518:20:02 <sgk> right 38618:20:35 <sgk> i think we can play that a little by ear 38718:20:47 <sgk> dev list for kicking around ideas 38818:21:02 <sgk> wiki page for final decisions and opinions that you want made part of the public record 38918:21:06 <GregNoel> play by ear makes sense. 39018:21:30 <garyo> Has Russel(?) converted SCons to an hg repo? Or did someone else? 39118:21:47 <sgk> i think he has both a bzr and hg repo somewhere? 39218:22:07 <garyo> That's good news, means our cutover may be smooth. 39318:22:18 <sgk> i know he's a bug fan of bzr and Launchpad 39418:22:18 <sgk> big 39518:22:28 <garyo> yep 39618:22:33 <GregNoel> or even a big bug fan... 39718:22:54 <jason_at_intel> I believe there is a BZR and HG repro out there 39818:23:00 <sgk> i'll probably start two pages, one to hold brainstorming on the task list (and sign up volunteers) 39918:23:10 <sgk> and one to discuss pros + cons of code.google.com and bitbucket 40018:23:24 <garyo> That sounds great 40118:23:37 <GregNoel> sgk, you can use /Discussion pages for some of that. 40218:23:50 <sgk> GregNoel: good point 40318:23:35 <garyo> ok, I think I'm going to sign off now & get some sleep. This is all good progress & thought. 40418:23:36 <sgk> (<1 minute to shuttle end) 40518:24:03 <sgk> okay, gotta go -- thanks everyone, lot of good work tonight 40618:24:07 <garyo> g'night 40718:24:12 <jason_at_intel> well good night all.. till next time 40818:24:16 <GregNoel> Looks like it's over tonight; g'night all. 40918:24:20 * sgk (~sgk@67.218.110.174) has left #SCONS 41018:24:26 * garyo (~garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has left #SCONS 41118:24:33 * jason_at_intel has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.6/20100625231939]) 41218:44:15 * loonycyborg has quit (Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz) 41321:13:39 * bdbaddog has quit (Read error: Connection reset by peer) 414