IrcLog2010 05 11
William Deegan edited this page Jan 14, 2016
·
2 revisions
16:41:21 * 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
16:48:31 * Jason_at_Intel (~[chatzilla@12.18.240.224](mailto:chatzilla@12.18.240.224)) has joined #SCONS
16:54:00 * bdbaddog (~[bdeegan@adsl-71-131-4-109.dsl.sntc01.pacbell.net](mailto:bdeegan@adsl-71-131-4-109.dsl.sntc01.pacbell.net)) has joined #SCONS
16:59:05 * [GregNoel](GregNoel) is no longer marked as being away
16:59:22 * sgk (~sgk@nat/google/x-vbtwdjatbsgoccdr) has joined #SCONS
16:59:23 <[GregNoel](GregNoel)> Hi, guys; I don't see Steven yet, but are we ready to go otherwise?
16:59:42 <[GregNoel](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](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](GregNoel)> 2609, consensus
17:00:52 <[GregNoel](GregNoel)> 2498, consensus
17:00:59 <garyo> yep
17:01:00 <[GregNoel](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](GregNoel)> At 2.x p3, it's possible that it might be overrun by doing something with IAPAT.
17:02:39 <sgk> [GregNoel](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](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](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](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](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](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](GregNoel)> Hmmm... Maybe [FutureProjects](FutureProjects)?
17:06:38 <sgk> [GregNoel](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](GregNoel)> I'll add it to [FutureProjects](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](GregNoel)> sgk, that'll work, too...
17:07:29 <Jason_at_Intel> fyi
17:07:47 <Jason_at_Intel> the issue is that [AddOption](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](GregNoel)> 2612 consensus
17:07:55 <garyo> 2612, 2613 consensus both
17:08:05 <[GregNoel](GregNoel)> 2614
17:08:39 <[GregNoel](GregNoel)> It should use Action._subproc() to get the right shell environment.
17:09:06 <garyo> right meaning default?
17:09:53 <[GregNoel](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](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](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](GregNoel)> Since it's a regression, 1.3.1 p1?
17:18:57 <sgk> ++
17:19:10 <bdbaddog> k.
17:19:20 <[GregNoel](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](GregNoel)> 2615?
17:20:02 <[GregNoel](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](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](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](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](GregNoel)> OK, that works for me.
17:23:33 <sgk> thx
17:23:39 <[GregNoel](GregNoel)> 2.1 p2 Gary.
17:23:46 <[GregNoel](GregNoel)> 2617?
17:23:50 <[GregNoel](GregNoel)> consensus
17:24:02 <[GregNoel](GregNoel)> 2618, consensus
17:24:10 <[GregNoel](GregNoel)> 2619, consensus
17:24:18 <[GregNoel](GregNoel)> 2620
17:24:31 <garyo> consensus too, I agree w/ wontfix
17:24:38 <[GregNoel](GregNoel)> done
17:24:42 <sgk> agreed
17:24:49 <[GregNoel](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](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](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](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](GregNoel)> so 2621 wontfix?
17:26:56 <garyo> Greg: I agree w/ that.
17:26:54 <[GregNoel](GregNoel)> done.
17:27:02 <[GregNoel](GregNoel)> 2622?
17:27:13 <garyo> agree w/ sgk.
17:27:18 <garyo> 2.1 p1 sk
17:27:25 <[GregNoel](GregNoel)> done
17:27:34 <[GregNoel](GregNoel)> 2623, consensus
17:27:41 <[GregNoel](GregNoel)> 2624
17:28:05 <[GregNoel](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](mailto: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](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](GregNoel)> sonw
17:29:41 <[GregNoel](GregNoel)> oops, done
17:29:47 <sgk> i like "sonw" myself
17:29:52 <[GregNoel](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](GregNoel)> works for me; same milestone/pri?
17:30:55 <garyo> yes.
17:31:01 <[GregNoel](GregNoel)> done
17:31:13 <[GregNoel](GregNoel)> 2626, consensus
17:31:21 <[GregNoel](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](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](GregNoel)> I'm waiting for bug reports
17:33:17 <sgk> [GregNoel](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](GregNoel)> The warnings need to be changed to errors
17:34:16 <[GregNoel](GregNoel)> and converting [UserFoo](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](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](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](GregNoel)> sgk, new-style classes won't work for everything; I've been burned trying to convert some. [NullSeq](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](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](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](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](GregNoel)> Warnings==>errors, you're best, but I have a couple of thoughts...
17:43:40 <[GregNoel](GregNoel)> Possibly some [UserFoo](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](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](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](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](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](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](GregNoel)> sgk, I think so.
17:47:43 <Jason_at_Intel> as in env.Copy is removed
17:47:46 <sgk> * [GregNoel](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](DeprecationCycle))
17:48:52 <sgk> ([GregNoel](GregNoel) did the heavy lifting of defining the steps)
17:49:04 <sgk> garyo: ah, right
17:49:14 <[GregNoel](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](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](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](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](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](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/](http://python.org/dev/peps/pep-0374/)
18:00:46 <bdbaddog> [http://python.org/dev/peps/pep-0385/](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](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](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/](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](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](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/](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](ChatZilla) 0.9.86 [Firefox 3.5.3/20090824101458])
18:15:21 <[GregNoel](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](mailto:garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)) has left #SCONS
18:15:48 * [GregNoel](GregNoel) has been marked as being away