Wiki

Clone wiki

SCons / BugParty / IrcLog2010-05-11

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

Updated