Please note:The SCons wiki is now restored from the attack in March 2013. All old passwords have been invalidated. Please reset your password if you have an account. If you note missing pages, please report them to webmaster@scons.org. Also, new account creation is currently disabled due to an ongoing spam flood (2013/08/27).
   1 16:41:21 *	garyo (~garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS
   2 16:48:31 *	Jason_at_Intel (~chatzilla@12.18.240.224) has joined #SCONS
   3 16:54:00 *	bdbaddog (~bdeegan@adsl-71-131-4-109.dsl.sntc01.pacbell.net) has joined #SCONS
   4 16:59:05 *	GregNoel is no longer marked as being away
   5 16:59:22 *	sgk (~sgk@nat/google/x-vbtwdjatbsgoccdr) has joined #SCONS
   6 16:59:23 <GregNoel>	Hi, guys; I don't see Steven yet, but are we ready to go otherwise?
   7 16:59:42 <GregNoel>	Oops, there he is.
   8 16:59:42 <sgk>	just got here
   9 16:59:46 <Jason_at_Intel>	he just logged in
  10 16:59:52 <sgk>	i'm sneaky that way
  11 17:00:00 <GregNoel>	{;-}
  12 17:00:09 <garyo>	Hi folks
  13 17:00:14 <Jason_at_Intel>	hi all
  14 17:00:29 <bdbaddog>	Hi!
  15 17:00:39 <sgk>	ready when everyone else is
  16 17:00:41 <GregNoel>	2609, consensus
  17 17:00:52 <GregNoel>	2498, consensus
  18 17:00:59 <garyo>	yep
  19 17:01:00 <GregNoel>	2611
  20 17:01:23 <garyo>	Looks like Steven's to me...
  21 17:01:29 <sgk>	yep
  22 17:01:40 <garyo>	2.x p3 sgk?
  23 17:01:46 <sgk>	Jaston_at_Intel:  good point re: grouping
  24 17:02:02 <Jason_at_Intel>	thanks
  25 17:02:08 <sgk>	the intent is that our API is supposed to look like optparse's enough to allow things like that
  26 17:02:18 <sgk>	but we probably have to expose some additional pieces to make grouping work
  27 17:02:11 <Jason_at_Intel>	it is clear to see in Parts
  28 17:02:19 <Jason_at_Intel>	-h is useless
  29 17:02:22 <GregNoel>	At 2.x p3, it's possible that it might be overrun by doing something with IAPAT.
  30 17:02:39 <sgk>	GregNoel:  fair enough, if that happens
  31 17:02:57 <Jason_at_Intel>	I making a first stab at this in part with my own iapat light object
  32 17:03:21 <garyo>	I'll be interested to see it
  33 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 ...
  34 17:03:58 <GregNoel>	... it was intended to be backward compatible, so it didn't have a lot of wiggle room.
  35 17:03:50 <Jason_at_Intel>	would like to read your thoughts.. I will look for it myself when i get back to that
  36 17:03:50 <sgk>	btw, what does IAPAT specifically stand for?
  37 17:04:07 <garyo>	Info About Platform And Tools :)
  38 17:04:14 <sgk>	k, thx
  39 17:04:22 <Jason_at_Intel>	I had a better name.. but forgot to write it down...
  40 17:04:35 <garyo>	Greg named it that because it was so ugly we'd be forced to not use it, I think.
  41 17:04:43 <GregNoel>	exactly
  42 17:04:40 <garyo>	So don't.
  43 17:04:54 <sgk>	IAPAT works, the SConsFutureProjects wiki page shows up #5 when you google it
  44 17:04:56 <Jason_at_Intel>	:-)
  45 17:05:11 <garyo>	:-/
  46 17:05:36 <sgk>	back to the task at hand...
  47 17:05:41 <GregNoel>	In any event, I'll go with 2.x p3 for 2611
  48 17:05:42 <sgk>	2611:  2.x p3 sgk for a quick fix
  49 17:05:49 <garyo>	agreed.
  50 17:05:50 <GregNoel>	done
  51 17:06:03 <sgk>	do we need an issue for longer-term "clean up Help()" ?
  52 17:06:11 <garyo>	sgk: +1
  53 17:06:42 <garyo>	(specifically, handle grouping I guess -- otherwise it's not so bad now really)
  54 17:06:29 <GregNoel>	Hmmm...  Maybe FutureProjects?
  55 17:06:38 <sgk>	GregNoel++
  56 17:06:51 <sgk>	we have enough tigris.org issues to sort through as it is
  57 17:07:11 <garyo>	ok I guess
  58 17:07:18 <GregNoel>	I'll add it to FutureProjects
  59 17:07:20 <sgk>	I'll add it to SConsFutureProjects while we're discussing the rest
  60 17:07:29 <sgk>	too late, i already clicked... :-)
  61 17:07:32 <garyo>	thx
  62 17:07:43 <GregNoel>	sgk, that'll work, too...
  63 17:07:29 <Jason_at_Intel>	fyi
  64 17:07:47 <Jason_at_Intel>	the issue is that AddOption conflict with this at times
  65 17:08:19 <sgk>	Jason_at_Intel:  "...conflict with this..."  this == ??
  66 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
  67 17:06:02 <GregNoel>	2612 consensus
  68 17:07:55 <garyo>	2612, 2613 consensus both
  69 17:08:05 <GregNoel>	2614
  70 17:08:39 <GregNoel>	It should use Action._subproc() to get the right shell environment.
  71 17:09:06 <garyo>	right meaning default?
  72 17:09:53 <GregNoel>	Default, picked up from env, whatever.
  73 17:10:17 <garyo>	I see, there's a function in there get_default_ENV.
  74 17:10:32 <garyo>	But for running bat scripts shouldn't we start with as little imported as possible?
  75 17:10:40 <GregNoel>	Yeah, that's a worst case, but it'll do the right thing.
  76 17:11:21 <Jason_at_Intel>	have we tried to build with vs2010 and a windows server system?
  77 17:11:33 <garyo>	Jason: I bet not.
  78 17:11:39 <Jason_at_Intel>	i have reason to believe that the script don't work there
  79 17:11:48 <garyo>	But why do you ask?  Does its bat script need shell vars?
  80 17:12:14 <Jason_at_Intel>	well the .net stuff will not setup correctly
  81 17:12:32 <Jason_at_Intel>	so unless you import it from the shell it might not work
  82 17:12:53 *	sgk now agrees that Action._subproc() should be used here; we need more consistency w.r.t. invoking commands, not less
  83 17:13:00 <garyo>	Right now it's importing the user's whole env.  We're talking about cutting out most/all of that.
  84 17:13:21 <bdbaddog>	is that a 1.3 fix?
  85 17:13:28 <bdbaddog>	Action._subproc() ?
  86 17:13:30 <garyo>	sgk/Greg: I see the point about Action._subproc.  It's quite valid.
  87 17:13:38 <Jason_at_Intel>	Action._subproc (.. does this do a subversion call?)
  88 17:14:00 <sgk>	no, it's just a way to invoke an external command (subprocess)
  89 17:14:13 <sgk>	using the Environment's ENV, not whatever's in os.environ
  90 17:14:21 <Jason_at_Intel>	sorry ment subprcess
  91 17:14:50 <sgk>	one of the dumber early SCons design decisions was using the user's external environment to toolchain detection
  92 17:14:54 <sgk>	instead of ENV['PATH']
  93 17:14:51 <Jason_at_Intel>	does it hide the output, or have an option for that?
  94 17:14:57 <garyo>	Jason: yes, most of it is setting up the proper env to pass to subprocess.Popen.
  95 17:15:28 <garyo>	Jason: it handles stdin/stdout/stderr.
  96 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
  97 17:16:02 <garyo>	bdbaddog: ideally yes for 1.3, it is a regression after all.  What do you think?
  98 17:16:16 <garyo>	jason: it's in Action.py.
  99 17:20:09 <garyo>	With _subproc, we'd pass env=None here since there's no env at that point.
 100 17:20:21 <garyo>	But it should still work OK.
 101 17:17:15 <bdbaddog>	garyo: I'll have to take a look at the change, but likely 1.3.
 102 17:17:23 <bdbaddog>	though pre/post 1.3.1 ?
 103 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.
 104 17:17:48 <bdbaddog>	yes. I agree.
 105 17:17:56 <garyo>	1.3.1 if possible.
 106 17:18:05 <sgk>	agreed, 1.3.1 if possible
 107 17:18:18 <sgk>	unless it would hold up too long
 108 17:18:20 <garyo>	(that way maybe we never have to do 1.3.2 :-))
 109 17:18:36 *	sgk likes the sound of no 1.3.2
 110 17:18:45 <garyo>	1.3.1, p3.  I'll help w/ it.
 111 17:18:49 <bdbaddog>	I'd put $10 on there'll be a 1.3.2
 112 17:18:50 <GregNoel>	Since it's a regression, 1.3.1 p1?
 113 17:18:57 <sgk>	++
 114 17:19:10 <bdbaddog>	k.
 115 17:19:20 <GregNoel>	done
 116 17:19:21 <bdbaddog>	I'll take a wack at it tonight and push another checkpiont if I can.
 117 17:19:37 <sgk>	and it can be pushed if there's a good reason (it's too hairy, unintended side effects, etc.)
 118 17:19:29 <GregNoel>	2615?
 119 17:20:02 <GregNoel>	There's basic agreement on 2615, but the details need to be pinned down.
 120 17:20:25 <sgk>	which 2615 details?  2.2 vs. 2.1 ?
 121 17:20:47 <GregNoel>	sgk, yes, also priority and owner.
 122 17:20:40 <bdbaddog>	2.1
 123 17:21:09 <garyo>	2.1
 124 17:21:05 <sgk>	ah, I thought +Easy obviated those
 125 17:21:10 <sgk>	but I guess not for 2.1 / 2.2
 126 17:21:27 <sgk>	(< 5 minutes to interrupt to board shuttle)
 127 17:21:37 <GregNoel>	sgk, yes, for 2.x it's OK, but not for closer issues.
 128 17:21:56 <garyo>	p2 since it's a silent failure?
 129 17:22:01 <sgk>	p2 sounds good
 130 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
 131 17:22:13 <sgk>	i already looked, i can take if no one else volunteers
 132 17:22:20 <GregNoel>	2.1 p2 works for me.
 133 17:22:53 <sgk>	oh, wait, i was thinking about 2618
 134 17:22:57 <garyo>	jason: env=None will work.
 135 17:23:14 <garyo>	2615: I can do it.
 136 17:23:29 <GregNoel>	OK, that works for me.
 137 17:23:33 <sgk>	thx
 138 17:23:39 <GregNoel>	2.1 p2 Gary.
 139 17:23:46 <GregNoel>	2617?
 140 17:23:50 <GregNoel>	consensus
 141 17:24:02 <GregNoel>	2618, consensus
 142 17:24:10 <GregNoel>	2619, consensus
 143 17:24:18 <GregNoel>	2620
 144 17:24:31 <garyo>	consensus too, I agree w/ wontfix
 145 17:24:38 <GregNoel>	done
 146 17:24:42 <sgk>	agreed
 147 17:24:49 <GregNoel>	2621
 148 17:25:01 <sgk>	put our time into a framework for externally-developed tools
 149 17:25:05 <garyo>	let's try to make them do it externally, see if it works.
 150 17:25:24 <GregNoel>	(garyo, BTW, both go and vala generate C-compatible code)
 151 17:25:26 <sgk>	guess that raises the priority of some of the runtest.py refactoring to support that
 152 17:25:30 <garyo>	(did that make sense?)
 153 17:25:35 <sgk>	shuttle's here, biab
 154 17:25:38 *	sgk has quit (Quit: sgk)
 155 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']
 156 17:25:56 <garyo>	Greg: I didn't know that about Go.  But of course you're right.
 157 17:26:18 <GregNoel>	garyo, it uses GCC's backend.
 158 17:26:46 <garyo>	Greg: so both of them will be good testcases to see if this can be done outside the core.
 159 17:26:54 <GregNoel>	I agree.
 160 17:26:24 <garyo>	Jason: right, you'll end up in get_default_ENV which is fine.
 161 17:26:43 <Jason_at_Intel>	but not {} which is clean in cases like msvc
 162 17:26:44 <GregNoel>	so 2621 wontfix?
 163 17:26:56 <garyo>	Greg: I agree w/ that.
 164 17:26:54 <GregNoel>	done.
 165 17:27:02 <GregNoel>	2622?
 166 17:27:13 <garyo>	agree w/ sgk.
 167 17:27:18 <garyo>	2.1 p1 sk
 168 17:27:25 <GregNoel>	done
 169 17:27:34 <GregNoel>	2623, consensus
 170 17:27:41 <GregNoel>	2624
 171 17:28:05 <GregNoel>	I'll go with 2.1 p2, but it needs an owner.
 172 17:28:18 <Jason_at_Intel>	2624 was dup?
 173 17:28:21 *	sgk (~sgk@67.218.107.117) has joined #SCONS
 174 17:28:37 <garyo>	Seems a lot like 2615 which is mine.  I'll at least try it.
 175 17:28:38 <sgk>	back
 176 17:28:53 <sgk>	which?
 177 17:29:07 <GregNoel>	sgk, welcome; garyo, I'll agree; sgk, 2624.
 178 17:29:09 <garyo>	we're on 2624.
 179 17:29:28 <sgk>	yeah, sounds right
 180 17:29:37 <GregNoel>	sonw
 181 17:29:41 <GregNoel>	oops, done
 182 17:29:47 <sgk>	i like "sonw" myself
 183 17:29:52 <GregNoel>	2625
 184 17:29:54 <garyo>	2624: 2.1 p2 garyo, and I think 2625 is the same kind of thing too, right?
 185 17:30:17 <sgk>	yeah, if you want it
 186 17:30:19 <garyo>	Just your basic error handling?  I can do that.
 187 17:30:23 <sgk>	cool
 188 17:30:43 <GregNoel>	works for me; same milestone/pri?
 189 17:30:55 <garyo>	yes.
 190 17:31:01 <GregNoel>	done
 191 17:31:13 <GregNoel>	2626, consensus
 192 17:31:21 <GregNoel>	Wow, we're done....
 193 17:31:29 <sgk>	excellent
 194 17:31:38 <sgk>	i was surprised by how many new ones we had to go through
 195 17:31:44 <sgk>	people must be using the software, or something...
 196 17:31:48 <garyo>	:-)
 197 17:31:55 <GregNoel>	And there are five more since Saturday
 198 17:31:55 <bdbaddog>	yes. lots of email traffic on lists too of late.
 199 17:32:05 <bdbaddog>	DRCS discussion anyone?
 200 17:32:08 <sgk>	any other discussion topics?
 201 17:32:13 <sgk>	...like that one...
 202 17:32:15 <sgk>	:-)
 203 17:32:17 <bdbaddog>	or 2.0 and how far from being ready?
 204 17:32:25 <sgk>	2.0 first
 205 17:32:27 <garyo>	Has anyone tried the 2.0 checkpoint yet?
 206 17:32:36 <garyo>	I mean on real code?
 207 17:32:37 <Jason_at_Intel>	I tested it.. it is working great for me so far
 208 17:32:39 <bdbaddog>	ran runtests on all the packages.
 209 17:32:58 <Jason_at_Intel>	I built all our product with it ( and Parts .. no issues found so far)
 210 17:33:16 <Jason_at_Intel>	which is about 6 different product at the moment
 211 17:33:03 <garyo>	I want to try it tomorrow on my win7 box on our real codebase.  I'll let you know.
 212 17:33:10 <bdbaddog>	x64 ?
 213 17:33:12 <garyo>	Jason: that's impressive.
 214 17:33:12 <GregNoel>	I'm waiting for bug reports
 215 17:33:17 <sgk>	GregNoel:  are there any additional nice-to-have issues for 2.0 that we kicked to lower priority?
 216 17:33:33 <sgk>	but that we should maybe try to get in for release?
 217 17:33:41 <GregNoel>	The warnings need to be changed to errors
 218 17:34:16 <GregNoel>	and converting UserFoo to builtin classes is scheduled for 2.1.
 219 17:33:30 <garyo>	bdbaddog: I'll build x64 and x86.
 220 17:33:31 <Jason_at_Intel>	used win7 x64
 221 17:33:42 <Jason_at_Intel>	have not tried linux yet
 222 17:33:45 <Jason_at_Intel>	or mac
 223 17:33:56 <bdbaddog>	we need to push some bug fixes from 1.3.x Ithink for MSVC
 224 17:34:02 <garyo>	OK, maybe I'll try linux tmw instead of Win.
 225 17:34:26 <sgk>	bdbaddog:  how many 1.3.x changes in the queue?  enough to check by hand?
 226 17:34:36 <garyo>	bdbaddog: you're right, 2.0 has to have the 1.3.x fixes (there aren't many)
 227 17:34:40 <bdbaddog>	hmm. I'll have to diff the msvc sutff.
 228 17:34:45 <bdbaddog>	shouldnt' be much.
 229 17:34:58 <bdbaddog>	but will include this latest issue from today right?
 230 17:34:46 <Jason_at_Intel>	what is teh view in using new style class for all the Scons classes?
 231 17:35:21 <sgk>	bdbaddog:  yes, at this point, anything in 1.3.[1x] sould go in 2.0 to avoid regressions
 232 17:35:26 <sgk>	barring good reasons to the contrary
 233 17:35:01 <sgk>	i thought bdbaddog did one 1.3.x fix earlier on that GregNoel backed out of trunk
 234 17:35:15 <bdbaddog>	didn't know it got backed out.
 235 17:35:40 <sgk>	it did, but then it seemed to have gotten put back in
 236 17:35:51 <sgk>	it got backed out to keep the fixer work on a stable base
 237 17:36:03 <sgk>	since there was a lot of stuff happening
 238 17:35:59 <bdbaddog>	k.
 239 17:36:20 <garyo>	anyway, we can pretty easily merge it now I think.
 240 17:36:25 <bdbaddog>	o.k. will do.
 241 17:36:30 <sgk>	Jason_at_Intel:  we should transition to using new-style classes for everything
 242 17:36:42 <Jason_at_Intel>	I agree
 243 17:36:41 <sgk>	GregNoel:  think we should do that for 2.0?
 244 17:36:53 <garyo>	Isn't that a huge change?
 245 17:37:03 <sgk>	theoretically, no
 246 17:37:16 <sgk>	syntactically, it's just adding deriving all classes from (object)
 247 17:36:53 <Jason_at_Intel>	I was think we do want that for 2.0
 248 17:37:09 <Jason_at_Intel>	just change class XXX(object)
 249 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.
 250 17:37:25 <sgk>	ugh
 251 17:37:45 <garyo>	They're faster, right?  Maybe start with Environment, Node, FS?
 252 17:38:03 <Jason_at_Intel>	I think there will be benefit in doing this long term
 253 17:38:03 <bdbaddog>	can fixer do that?
 254 17:38:49 <garyo>	(silence)
 255 17:39:04 <sgk>	yeah, but what we probably really want is to still do them one by one with testing to isolate problems
 256 17:39:17 <bdbaddog>	o.k.
 257 17:39:24 <sgk>	my system's reasonably fast, I could take a stab at converting whatever doesn't break the tests
 258 17:39:36 <bdbaddog>	sounds good..
 259 17:39:38 <sgk>	that means at least one more checkpoint, of course
 260 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.
 261 17:40:02 <garyo>	sounds good to me
 262 17:40:16 <sgk>	GregNoel:  sounds like that strikes the right balance
 263 17:40:42 <sgk>	okay, so for 2.0 work, i've heard:
 264 17:40:59 <sgk>	* bdbaddog makes sure all 1.3.x changes are present in trunk
 265 17:41:14 <sgk>	* sgk takes a stab at converting individual classes to new-style classes
 266 17:41:15 <bdbaddog>	MSVC changes..
 267 17:41:32 <sgk>	in addition to those in 1.3.x ?
 268 17:41:59 <GregNoel>	(finish the list, then talk?)
 269 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.
 270 17:42:08 <bdbaddog>	yes
 271 17:42:13 <sgk>	* change warnings to errors:  who?  (I can)
 272 17:42:55 <sgk>	is that it?
 273 17:42:57 <GregNoel>	Warnings==>errors, you're best, but I have a couple of thoughts...
 274 17:43:40 <GregNoel>	Possibly some UserFoo to builtin classes, but they've been biting back, probably should leave those to 2.1...
 275 17:43:46 <sgk>	oh, do we have anything on additional things scheduled for deprecation that need warnings turned on in 2.0?
 276 17:44:09 <GregNoel>	sgk, good point...
 277 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
 278 17:44:34 <sgk>	Jason_at_Intel:  agreed, but not for 2.0
 279 17:44:51 <Jason_at_Intel>	Agreed .. more of 2.x or 3.x feature
 280 17:45:22 <Jason_at_Intel>	but internally such a fix would help maintainability of the code
 281 17:45:21 <sgk>	heh
 282 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?
 283 17:45:43 <sgk>	http://www.scons.org/wiki/DeprecatedFeatures shows whole bunches of things slated for "Mandatory Warnings" in 1.3
 284 17:45:57 <sgk>	and "Fatal errors" in 2.0
 285 17:46:01 <sgk>	looks like we've missed that boat
 286 17:47:04 <GregNoel>	Yep, that's the page.
 287 17:46:25 <sgk>	eh, some of them we did do, the table is just out of date
 288 17:46:53 <Jason_at_Intel>	so do make the warning Scons error or do they become python errors.... like env.Copy() for example?
 289 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?
 290 17:47:14 <GregNoel>	sgk, I think so.
 291 17:47:43 <Jason_at_Intel>	as in env.Copy is removed
 292 17:47:46 <sgk>	* GregNoel lists any additional deprecated work
 293 17:48:18 <sgk>	Jason_at_Intel:  check that wiki page, it has a step-by-step process for deprecating things
 294 17:48:24 <sgk>	ending up with their complete removal
 295 17:48:35 <Jason_at_Intel>	ok
 296 17:48:41 <sgk>	but only after we've given people lots of time to adapt
 297 17:48:46 <garyo>	(actually that's DeprecationCycle)
 298 17:48:52 <sgk>	(GregNoel did the heavy lifting of defining the steps)
 299 17:49:04 <sgk>	garyo:  ah, right
 300 17:49:14 <GregNoel>	(I think I'm having network problems, my IRC update is in fits and starts and my spreadsheet just crashed.)
 301 17:49:52 <GregNoel>	sgk, can you post that list somewhere?
 302 17:50:10 <bdbaddog>	sgk: and/or email to release list
 303 17:50:15 <sgk>	i'll email to release
 304 17:50:34 <GregNoel>	good, thanks
 305 17:50:51 <bdbaddog>	DRCS then?
 306 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:
 307 17:52:13 <garyo>	github vs. what's mercurial's hub vs. launchpad.
 308 17:52:25 <bdbaddog>	or google code..
 309 17:52:32 <garyo>	yes, that too.
 310 17:52:35 <sgk>	being able to use subversion to get things from github just feels perverse
 311 17:52:42 <garyo>	:-)
 312 17:52:53 <Jason_at_Intel>	so the end result is we dump tigris?
 313 17:53:05 <sgk>	end result, i think so
 314 17:53:09 <garyo>	Jason: and/or sourcforge.
 315 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.
 316 17:53:30 <sgk>	yeah
 317 17:53:40 <Jason_at_Intel>	then it seems that the site feature are important as well
 318 17:53:48 <Jason_at_Intel>	since there is bug tracking and such
 319 17:53:41 <bdbaddog>	I'd vote git or hg, just because I'm already using both of those for different projects.
 320 17:53:44 <garyo>	Greg: not sure about that.  They're all well abovecritical mass imho.
 321 17:54:00 <sgk>	i think he means traction within our little circle
 322 17:54:11 <garyo>	ah, well that I can agree with!
 323 17:54:33 <GregNoel>	sgk, yes (updates still in fits and starts)
 324 17:54:35 <Jason_at_Intel>	I tend to like launchpad ...
 325 17:54:35 <bdbaddog>	github is pretty nice for managing different users with pull requests and such
 326 17:55:02 <sgk>	thinking on this more, i think one of the underlying disconnects
 327 17:55:15 <sgk>	is that it's not clear how much weight to give certain aspects of the decision
 328 17:55:40 <sgk>	i'm specifically thinking of whether or not the SVN transition should be a big factor
 329 17:55:59 <garyo>	what do you mean?
 330 17:56:24 <sgk>	if we're basically ending up not using SVN (except for read-only browsing)
 331 17:56:50 <sgk>	then maybe all of the attention on "is hgsubversion / git-svn / bzr-* good enough" is wasted effort
 332 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
 333 17:57:11 <bdbaddog>	sgk: I totally agree. who cares about SVN, we're gonna end up off it anyway.
 334 17:57:44 <garyo>	i get it
 335 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
 336 17:57:57 <Jason_at_Intel>	So what is wrong with SVN as the central hub?
 337 17:58:06 <sgk>	that stuff is old and hairy as it is
 338 17:58:07 <bdbaddog>	commit rights management.
 339 17:58:16 <GregNoel>	I'd rather ease into the choice; CVS->SVN was too traumatic, and it was supposed to be simple.
 340 17:58:28 <bdbaddog>	with git, (or other) we have an owner for a repo which takes pull requests..
 341 17:58:29 <Jason_at_Intel>	sure... but that is not really different in DVCS
 342 17:58:43 <Jason_at_Intel>	you can just make your own branch so do what you like
 343 17:58:51 <bdbaddog>	jason: take a look at how buildbot manages patches.
 344 17:59:11 <garyo>	jason: all the *-svn workflows are more complicated than pure hg/git/bzr.
 345 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.
 346 17:59:32 <Jason_at_Intel>	I get that
 347 17:59:43 <Jason_at_Intel>	you can diff different repositories
 348 17:59:53 <Jason_at_Intel>	makes life easier
 349 18:00:18 <garyo>	ok, rather than debating the merits of each one, as sgk says let's consider where the weights go.
 350 18:00:39 <bdbaddog>	http://python.org/dev/peps/pep-0374/
 351 18:00:46 <bdbaddog>	http://python.org/dev/peps/pep-0385/
 352 18:00:41 <sgk>	sounds like what we're really getting to is "what comes after tigris.org"
 353 18:00:42 <garyo>	IMHO the hub/site is perhaps as important as the actual s/w, since they're all roughly comparable.
 354 18:00:48 <sgk>	right
 355 18:00:52 <sgk>	what garyo said
 356 18:01:16 <bdbaddog>	I see no reason we must tie DRCS hosting to bugtracking.
 357 18:01:39 <sgk>	bdbaddog:  fair point
 358 18:01:41 <bdbaddog>	Simplify the decision. look for best hosting.
 359 18:01:51 <bdbaddog>	then best bug, or simplify and keep it at tigris.
 360 18:01:54 <bdbaddog>	for now.
 361 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.
 362 18:02:18 <sgk>	okay, let's just say the issue tracker stays at tigris.org
 363 18:02:19 <bdbaddog>	GregNoel: pretty much all bug trackers have xml export at this point.
 364 18:02:19 <Jason_at_Intel>	I would go for bzr or hg.. git is just window unfriendly
 365 18:02:29 <sgk>	ain't broke, don't fix it, and simplifies the rest of the decision just a bit
 366 18:02:37 <bdbaddog>	Then I'd vote for hg.
 367 18:03:00 <sgk>	Jason_at_Intel:  good point re: windows, i thought about that earlier today but forgot to mention
 368 18:03:01 <bdbaddog>	but I really like githubs forking/pull request mechanisms if git was a possiblity.
 369 18:03:03 <garyo>	I'd vote for hg or git.
 370 18:03:06 <bdbaddog>	or even better gerrit.
 371 18:03:23 <bdbaddog>	http://code.google.com/p/gerrit/
 372 18:03:33 <garyo>	git isn't as bad on windows as it used to be... but it still is less friendly there.
 373 18:03:37 <bdbaddog>	it's used by andriod and wraps git with code review
 374 18:03:44 <sgk>	gerrit scares me a bit because of the back-end automated merge and checkin
 375 18:04:01 <sgk>	but that was based on early discussions when it was still google internal
 376 18:04:05 <bdbaddog>	from the podcast it sounds like you do manual merge when there's conflicts
 377 18:04:28 <garyo>	trac and redmine are also excellent, and support git/hg at least, and maybe bzr
 378 18:04:29 <sgk>	can, my concern is bad merges that don't conflict
 379 18:04:46 <bdbaddog>	ahh. o.k.
 380 18:05:01 <bdbaddog>	can host a code reveiw enging on GAE..
 381 18:05:07 <bdbaddog>	engine that is
 382 18:05:21 <bdbaddog>	anyway.. somewhat secondary.
 383 18:05:31 <sgk>	gerrit's value add is really the code review process, though, isn't it?
 384 18:05:35 <bdbaddog>	yes.
 385 18:05:40 <garyo>	I see
 386 18:05:49 <sgk>	i don't know if any of us has the cycles for more formal code review
 387 18:05:51 <bdbaddog>	and it's git compatible so we can migrate to it I think if we choose git.
 388 18:05:58 <sgk>	even though it'd be a Good Thing conceptually
 389 18:06:05 <bdbaddog>	sgk:yes
 390 18:06:10 <garyo>	What I heard above seemed like hg is a noncontroversial choice for most of us.
 391 18:06:32 <garyo>	Some say git/hg, some say hg/bzr, but nobody seems to be anti-hg.
 392 18:06:35 <garyo>	?
 393 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.
 394 18:06:51 <sgk>	that sounds right
 395 18:06:58 <garyo>	plus it's in python
 396 18:06:59 <bdbaddog>	k. so hg, what timeframe?
 397 18:07:04 <bdbaddog>	2.0?
 398 18:07:06 <GregNoel>	Hg is good with me.
 399 18:07:08 <sgk>	what's the logical hg host?
 400 18:07:10 <Jason_at_Intel>	i like lauchpad
 401 18:07:23 <Jason_at_Intel>	what is the hg equal
 402 18:07:28 <sgk>	i thought launchpad was bzr ?
 403 18:07:38 <sgk>	k
 404 18:07:46 <Jason_at_Intel>	it is
 405 18:07:50 <sgk>	code.google.com supports hg
 406 18:07:55 <sgk>	not sure how well, though
 407 18:08:06 <garyo>	"bitbucket"?
 408 18:08:06 <bdbaddog>	I'm using bitbucket.org for one project.
 409 18:08:12 <Jason_at_Intel>	not sure of the hg site that would be like that
 410 18:08:23 <garyo>	bdbaddog: how is it?
 411 18:08:41 <bdbaddog>	decent, but it's just me right now in the project, so many of the issues dont' come into play
 412 18:08:48 <garyo>	sgk: we could do worse than code.google.com.
 413 18:08:51 <bdbaddog>	where's python hosted?
 414 18:09:07 <GregNoel>	I think my update is behind, but NOT 2.0, please.  2.1 maybe.
 415 18:09:24 <Jason_at_Intel>	bitbucket looks nice
 416 18:09:55 <garyo>	Agree w/ Greg.  Post-2.0, maybe between 2.0 and 2.1 or something.
 417 18:10:05 <sgk>	i agree re post-2.0
 418 18:10:17 <bdbaddog>	k. post 2.0
 419 18:10:39 <bdbaddog>	I'll create a dummy project on code.google.com and send out info and we can try it?
 420 18:11:00 <bdbaddog>	waf is hosted there..
 421 18:11:17 <sgk>	excellent!  we're in good company then... :-)
 422 18:11:48 <sgk>	bdbaddog:  do you want to create "scons" there, or some other experimental name for now?
 423 18:12:01 <garyo>	Just for info sake, I think python self-hosts their repo.
 424 18:12:04 <bdbaddog>	experimental. I'll see if I can import scons.
 425 18:12:28 <garyo>	bdbaddog: see good info in http://www.python.org/dev/peps/pep-0385/
 426 18:13:02 <sgk>	garyo:  excellent find
 427 18:13:02 <bdbaddog>	garyo: just sent that via this irc earlier.. ;)
 428 18:13:20 <garyo>	um, so you did. oops.
 429 18:13:28 <sgk>	bdbaddog:  excellent find
 430 18:13:43 <bdbaddog>	sgk: why thank u.. great minds think alike it seems..
 431 18:13:49 <sgk>	< 2 minutes to shuttle stop
 432 18:14:00 <bdbaddog>	k.
 433 18:14:01 <sgk>	okay, sounds like a plan
 434 18:14:10 <garyo>	maybe we're done for tonight, good job all
 435 18:14:14 <bdbaddog>	gnight everyone then..
 436 18:14:27 <Jason_at_Intel>	night
 437 18:14:47 <sgk>	thanks guys
 438 18:14:49 <sgk>	'night
 439 18:15:18 *	Jason_at_Intel has quit (Quit: ChatZilla 0.9.86 [Firefox 3.5.3/20090824101458])
 440 18:15:21 <GregNoel>	Looks like we're ending.  G'night, all.
 441 18:15:24 *	sgk has quit (Quit: sgk)
 442 18:15:35 <garyo>	good night.
 443 18:15:38 *	garyo (~garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has left #SCONS
 444 18:15:48 *	GregNoel has been marked as being away
 445 

BugParty/IrcLog2010-05-11 (last edited 2010-05-19 06:08:08 by ip68-7-77-81)