Wiki

Clone wiki

SCons / BugParty / IrcLog2010-08-03

16:41:49 * jason_at_intel (~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) has joined #SCONS 17:00:22 * GregNoel has arrived and is setting up 17:01:03 * bdbaddog (~bdeegan@adsl-71-131-10-196.dsl.sntc01.pacbell.net) has joined #SCONS 17:01:57 <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> 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> 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 bug? 17:05:25 <loonycyborg> That 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> 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> 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> 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 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 currently to reduce risk 17:17:11 <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: 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> 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> ... 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> done 17:25:00 <garyo> great. Sergey, reassign to me when you've got the patch. 17:25:26 <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 <- 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> 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) has joined #SCONS 17:27:03 <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> works for me; thanks. 17:28:13 <garyo> So back to 2629 now that sgk is back... 17:28:21 <GregNoel> Back to 2629? 17:28:37 <sgk> k 17:28:46 <sgk> 2.1 p1 sk is my vote 17:28:55 <GregNoel> done 17:29:00 <sgk> i should have filled in owner 17:29:11 <garyo> +1, thanks Steven 17:29:11 <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> done 17:29:55 <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> research p3? 17:31:25 <sgk> research p3 feels right to me 17:31:30 <GregNoel> done 17:31:37 <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> 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> 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> 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> 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> 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> so 2665 sk to capture test, then mark invalid? 17:40:57 * 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> 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> 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, 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> 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> garyo +1 17:47:44 <sgk> +1 17:47:49 <GregNoel> done 17:47:57 <GregNoel> 2667 17:48:05 <garyo> 2667: thanks Bill! 17:48:11 <bdbaddog> np. 17:48:45 <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> done 17:49:03 <GregNoel> 2670 17:49:21 <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> 2671 17:50:25 <garyo> 2671: I'll take that, integrate the patch & test. 17:50:34 <sgk> cool, thnx 17:50:32 <GregNoel> thanks; done 17:51:06 <GregNoel> 2672 already discussed 17:51:16 <GregNoel> 2114 17:52:02 <garyo> Agree we need to reassign... but who's doing any Fortran? 17:52:32 <GregNoel> This looks more like user error to me 17:53:00 <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> 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.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> 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> 2.x p4 sk is fine 17:55:16 <sgk> done 17:55:17 <GregNoel> consensus? 17:55:25 <bdbaddog> +1 17:55:32 <jason_at_intel> +1 17:55:28 <GregNoel> 2128 17:56:08 <sgk> 2128: 2.1 p3 sk (looks pretty quick) 17:56:17 <garyo> thanks 17:56:19 <GregNoel> done; thanks 17:56:31 <GregNoel> 2249 17:57:16 <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> 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> 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> done 17:59:01 <GregNoel> 2521? 17:59:16 <GregNoel> bypass? 17:59:34 <bdbaddog> sure. til next time. 17:59:35 <sgk> defer 17:59:40 <GregNoel> done 17:59:52 <GregNoel> 2575 bypass? 18:00:02 <sgk> sure 18:00:30 <GregNoel> seeing no other response, done 18:00:36 <GregNoel> 2630 18:00:52 <GregNoel> 2.1 p1 Steven? 18:01:03 <sgk> worksforme 18:01:07 <garyo> thanks! 18:01:21 <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> 2.1 p2 then? 18:02:14 <garyo> +1 18:02:20 <GregNoel> done 18:02:32 <GregNoel> That's it for today; good work. 18:02:42 <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> 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> 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> Gary, is the Hg server by-demand or persistent? Could we run it on scons.org? 18:11:59 <sgk> 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> <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 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> 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> 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> ... 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> 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> 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> sgk, you can use /Discussion pages for some of that. 18:23:50 <sgk> 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> Looks like it's over tonight; g'night all. 18:24:20 * sgk (~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) has left #SCONS 18:24:33 * jason_at_intel has quit (Quit: 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