1 16:41:49 *	jason_at_intel (~chatzilla@131.sub-75-207-82.myvzw.com) has joined #SCONS
   2 16:45:32 *	garyo (~garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS
   3 17:00:22 *	GregNoel has arrived and is setting up
   4 17:01:03 *	bdbaddog (~bdeegan@adsl-71-131-10-196.dsl.sntc01.pacbell.net) has joined #SCONS
   5 17:01:57 <GregNoel>	I don't see Steven, but it looks like a pretty full house.  Sergey, are you there?
   6 17:02:10 <loonycyborg>	Yes.
   7 17:02:14 <garyo>	Hi Sergey!
   8 17:02:23 <loonycyborg>	Hello.
   9 17:02:23 <GregNoel>	Are we ready to start?
  10 17:02:40 <garyo>	I think so
  11 17:02:41 <jason_at_intel>	I am ready
  12 17:02:45 <jason_at_intel>	are we going to wait for steven?
  13 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...
  14 17:03:39 <garyo>	mingw cmd line?
  15 17:03:50 <loonycyborg>	That guy had trouble linking libraries due to inherent limit on length of command lines in windows.
  16 17:03:54 <jason_at_intel>	Is that not a dup of TempFileMunge bug?
  17 17:05:25 <loonycyborg>	That TempFileMunge thingy doesn't seem to be used for mingw at all.
  18 17:05:37 <jason_at_intel>	Yep
  19 17:05:52 <loonycyborg>	Probably because mingw gcc < 4 doesn't support the @ indirection.
  20 17:05:59 <jason_at_intel>	I just looked..  there is no use of TEMPFILE in the tool
  21 17:06:11 <jason_at_intel>	this would have to be added to the tool, so it could be used
  22 17:06:31 <jason_at_intel>	what does it support?
  23 17:06:41 <jason_at_intel>	I believe the tempfile does not have to use @
  24 17:07:00 <garyo>	jason: gcc didn't used to support any kind of cmd files iirc.
  25 17:07:02 <loonycyborg>	What else can it do?
  26 17:07:35 <jason_at_intel>	does it work if you add the full command to the a batch file?
  27 17:07:51 <jason_at_intel>	grasping at straws here ...
  28 17:08:13 <garyo>	Sergey: if >=4.0 works could we just use tempfile in that case?
  29 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.
  30 17:09:07 <loonycyborg>	Probably yes. For lesser limits. There also are some in the shell iirc.
  31 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.
  32 17:09:33 *	sgk (~sgk@nat/google/x-gafuxkitacszsdsy) has joined #SCONS
  33 17:09:40 <sgk>	anyone still here?
  34 17:09:42 <jason_at_intel>	hi Steve!
  35 17:09:48 <garyo>	Hi Steven
  36 17:09:49 <GregNoel>	No, we've all left.
  37 17:09:52 <sgk>	sorry I'm later, got caught up debugging
  38 17:10:02 <sgk>	unfortunately, i still have to hike over to the shuttle
  39 17:10:29 <loonycyborg>	The standard practice is to build those objects into intermediate archives so command lines do not break the limit.
  40 17:10:41 <loonycyborg>	Perhaps scons could automate this somehow.
  41 17:10:56 <sgk>	(what number are we on?)
  42 17:10:54 <garyo>	sgk: we're talking about 2672, mingw line length limit
  43 17:11:17 <bdbaddog>	2672
  44 17:11:26 <jason_at_intel>	we jumped to 2672
  45 17:10:58 <sgk>	thx
  46 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
  47 17:11:44 <garyo>	(i.e. just document it)
  48 17:12:06 <loonycyborg>	It would be nice to abstract those details.
  49 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?
  50 17:12:18 <loonycyborg>	Would help with portability.
  51 17:12:40 *	sgk searches for the one he thought it was a dup of
  52 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.
  53 17:12:46 <bdbaddog>	can you specify the file as - and feed it stdout ?
  54 17:12:49 <garyo>	I'd be upset if my build tool suddenly built half my objects into a temp archive.
  55 17:13:14 <sgk>	http://scons.tigris.org/issues/show_bug.cgi?id=2628
  56 17:13:25 <garyo>	but the portability point is a good one, I admit
  57 17:13:38 <sgk>	not a dup of the specific circumstance (2628 puts it in the context of batch building)
  58 17:13:48 <sgk>	but now that i saw 2672, i think it's the general problem
  59 17:14:15 <sgk>	2628 has a code snippet that wraps shared object command lines with $(TEMPFILE{} by hand
  60 17:14:11 <garyo>	sgk: it's different because mingw doesn't support @ file indirection, so TEMPFILE doesn't work at all.
  61 17:14:21 <sgk>	aha
  62 17:14:33 <sgk>	okay, don't mind me... :-)
  63 17:14:34 <loonycyborg>	It does support it starting at gcc4
  64 17:15:26 <jason_at_intel>	so with gcc 4.1o there is @ support
  65 17:15:31 <jason_at_intel>	4.1.0
  66 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.
  67 17:16:23 <jason_at_intel>	I agree with gary
  68 17:16:51 <garyo>	anyone object?
  69 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
  70 17:17:11 <GregNoel>	Is there a decision?
  71 17:17:13 <garyo>	good point, Jason.
  72 17:17:24 <sgk>	k, i'll be back in ~6-8 minutes
  73 17:17:27 *	sgk has quit (Quit: sgk)
  74 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.
  75 17:18:01 <jason_at_intel>	Add tempFile.. and make the limit it uses to 8K for the ming tool
  76 17:18:15 <garyo>	Sergey, what do you think?
  77 17:18:17 <loonycyborg>	GregNoel: TEMPFILE could still help with 8K limit.
  78 17:19:05 <loonycyborg>	32K not so much because mingw does call ld commands that do break the limit too.
  79 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.
  80 17:20:00 <jason_at_intel>	the cmd.exe has a 8K limit for stuff it passes on the Commandline
  81 17:20:10 <GregNoel>	...  And I don't care.
  82 17:20:13 <garyo>	ok, so 2672, loonycyborg, 2.?, p?
  83 17:20:45 <garyo>	(Do'nt mean to sign you up unless you're OK w/ it, Sergey)
  84 17:20:33 <jason_at_intel>	so tempfile make a file that the exe can read to get really long commandlines
  85 17:21:03 <jason_at_intel>	it seem gcc has it own limit however that can break on linux
  86 17:21:12 <jason_at_intel>	that is why the @ option was added
  87 17:21:26 <jason_at_intel>	not a linux bug but a gcc one
  88 17:21:51 <garyo>	I suggest 2.2 p3 unless Sergey (or whoever) has time to do it for 2.1
  89 17:22:15 <jason_at_intel>	+1
  90 17:22:20 <loonycyborg>	Strictly speaking I can't do anything since I don't have commit access :P
  91 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)
  92 17:23:52 <garyo>	... crickets ...
  93 17:24:16 <bdbaddog>	no mingw here.
  94 17:24:19 <garyo>	so are we done with this one? :-)
  95 17:24:30 <bdbaddog>	+1 on done
  96 17:24:31 <loonycyborg>	I have several mingw setups, so I'll look into it..
  97 17:24:43 <GregNoel>	done
  98 17:25:00 <garyo>	great.  Sergey, reassign to me when you've got the patch.
  99 17:25:26 <GregNoel>	(Thanks Sergey)
 100 17:26:45 <loonycyborg>	Though I'm surprised that noone else here has a mingw setup.
 101 17:27:05 <loonycyborg>	http://nuwen.net/mingw.html <-  that mingw distro is easy to deploy.
 102 17:27:32 <garyo>	loonycyborg: I should try it.  I mostly use cygwin tools on windows, but Intel compiler.
 103 17:27:33 <jason_at_intel>	I had one... but i have no need to use it.. I have free window compiler
 104 17:25:01 <GregNoel>	moving on to 2629
 105 17:25:02 <jason_at_intel>	2629?
 106 17:25:49 <garyo>	2629: defer till sgk is back online?
 107 17:25:59 <jason_at_intel>	+1
 108 17:26:18 <garyo>	2671 then
 109 17:26:47 *	sgk (~sgk@67.218.110.174) has joined #SCONS
 110 17:27:03 <GregNoel>	Speaking of the devil...
 111 17:27:06 <sgk>	hello again
 112 17:27:07 <garyo>	Sigh, I'll take 2671 to test and commit it.  Make it p3 though.
 113 17:27:31 <GregNoel>	works for me; thanks.
 114 17:28:13 <garyo>	So back to 2629 now that sgk is back...
 115 17:28:21 <GregNoel>	Back to 2629?
 116 17:28:37 <sgk>	k
 117 17:28:46 <sgk>	2.1 p1 sk is my vote
 118 17:28:55 <GregNoel>	done
 119 17:29:00 <sgk>	i should have filled in owner
 120 17:29:11 <garyo>	+1, thanks Steven
 121 17:29:11 <GregNoel>	2650?
 122 17:29:38 <garyo>	no prob if it's delayed.  Mark as research p4 and we'll get to it when you're ready.
 123 17:29:39 <jason_at_intel>	what is SEP
 124 17:29:45 <garyo>	Scons Enhancement Proposal
 125 17:29:55 <garyo>	(see the wiki)
 126 17:29:57 <jason_at_intel>	ahh DUH :-)
 127 17:29:46 <GregNoel>	done
 128 17:29:55 <GregNoel>	2664?
 129 17:30:39 <bdbaddog>	I'll take it.
 130 17:30:41 <sgk>	go bill
 131 17:30:46 <garyo>	yay
 132 17:31:00 <sgk>	many thnx
 133 17:30:55 <GregNoel>	research p3?
 134 17:31:25 <sgk>	research p3 feels right to me
 135 17:31:30 <GregNoel>	done
 136 17:31:37 <GregNoel>	2665?
 137 17:31:56 <sgk>	i guess the key question is whether we want this sort of thing to "Just Work"
 138 17:31:58 <garyo>	Greg: are you sure we don't escape special chars in filenames?
 139 17:32:24 <GregNoel>	garyo, not absolutely positive, but I believe so.
 140 17:32:14 <sgk>	we don't
 141 17:32:19 <sgk>	or rather
 142 17:32:29 <sgk>	we kind of do some, but not well
 143 17:32:53 <garyo>	ok, so it sounds invalid then (except maybe for the space one, spaces are kinda important these days)
 144 17:33:06 <GregNoel>	Steven has it right.  There's an escape() function defined, but it doesn't do all that much.
 145 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\(\)
 146 17:33:37 <sgk>	with the backslashes in the file name
 147 17:33:44 <sgk>	so something somewhere did try to escape those
 148 17:33:45 <jason_at_intel>	is that what is used in the SPAWN functions?
 149 17:34:15 <sgk>	i personally like the idea that all of this gets cleaned up and supported by using subprocess
 150 17:34:21 <sgk>	am i dreaming?
 151 17:34:36 <bdbaddog>	sounds like a good dream to me.. ;)
 152 17:34:59 <jason_at_intel>	nope.. I though we are to look at this when i visit?
 153 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.
 154 17:35:10 <jason_at_intel>	see what i had done.. and see what is needed to make it work in SCOns
 155 17:35:21 <garyo>	+1
 156 17:35:34 <sgk>	so do we keep 2665 around to document the test case?
 157 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.
 158 17:35:50 <sgk>	smarter than we are, anyway... :-)
 159 17:36:22 <jason_at_intel>	It is... You can use the escape function with subprocess
 160 17:36:28 <jason_at_intel>	it will make the call fail
 161 17:36:35 <garyo>	either keep 2665 around or close as invalid and capture testcase elsewhere
 162 17:36:44 <sgk>	i had an idea about issues like this with good future test cases
 163 17:36:44 <jason_at_intel>	just saying from experience on this one
 164 17:37:07 <sgk>	what if we checked in the test case as a skipped test?
 165 17:37:41 <sgk>	with some message like "TODO:  issue 2661" or some such
 166 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.
 167 17:37:26 <garyo>	good idea
 168 17:37:57 <garyo>	the only hard part is remembering it's there, and un-skipping it when the time's right.
 169 17:38:01 <sgk>	they could be in a separate test/pending subdirectory
 170 17:38:23 <GregNoel>	sgk, that works.
 171 17:38:54 <sgk>	k, well let's add that to the mental toolbox of ways to handle issues
 172 17:39:05 <sgk>	since i suggested it, i can be the stuckee for that
 173 17:39:10 <garyo>	thanks!
 174 17:39:37 <sgk>	give me 2665, say, 2.x p4?  and I'll capture the test case
 175 17:39:47 <sgk>	do we have a "subprocess" or similar keyword for issues?
 176 17:39:48 <GregNoel>	so 2665 sk to capture test, then mark invalid?
 177 17:40:57 *	GregNoel is checking if there's a 'subprocess' keyword
 178 17:40:29 <sgk>	i can go either way
 179 17:40:43 <sgk>	invalid (with an explanation) if we just want to get it off the books
 180 17:41:08 <GregNoel>	get it off the books.
 181 17:41:47 <sgk>	ok by me
 182 17:42:06 <sgk>	I'll track down a recommended workaround and update the issue with it when i close it
 183 17:42:20 <sgk>	plus explain that we're checking in the test case for future
 184 17:42:16 <garyo>	perfect
 185 17:41:43 <garyo>	Don't we also have a quoting keyword or something like that?
 186 17:43:12 <GregNoel>	sgk, no subprocess keyword, garyo, use 'subst'
 187 17:44:06 <garyo>	Anyway sgk's going to close 2665 so keyword doesn't matter
 188 17:42:55 <garyo>	2666?
 189 17:43:22 <sgk>	3.0 feels right to me because of the incompatibility
 190 17:43:52 <sgk>	(bdbaddog:  this is an inconsistency with what's in CacheDir, not what's in .sconsign)
 191 17:44:01 <bdbaddog>	SGK: gotcha
 192 17:44:04 <jason_at_intel>	so is a false rebuild once on windows that big of an issue?
 193 17:45:05 <jason_at_intel>	besides you have to delete the directory every so often as it just grows
 194 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
 195 17:45:14 <garyo>	Jason: we have treated it that way in the past.
 196 17:45:52 <jason_at_intel>	I am not against it... I just don't see it as a big deal
 197 17:46:06 <sgk>	yeah, it not being a big deal also pushes it to 3.0 for me
 198 17:46:07 <jason_at_intel>	Changes  to builder have similar effects
 199 17:46:13 <garyo>	We could always make it optional now, then flip the switch in 3.0
 200 17:46:50 <GregNoel>	garyo, not a bad idea, but a lot of work.
 201 17:47:09 <garyo>	Greg: probably right.  Just throwing it out there.
 202 17:46:34 <jason_at_intel>	so most people expect a small rebuild when updating SCons
 203 17:46:45 <sgk>	it feels like a corner case (pulling out the same generated files across platforms) that isn't burning anybody down
 204 17:47:16 <sgk>	more than seems worth it given the small subset of people likely affected
 205 17:47:18 <jason_at_intel>	A switch is always safe
 206 17:47:29 <garyo>	So we're agreed 3.0 p3/p4?
 207 17:47:36 <bdbaddog>	+1
 208 17:47:38 <GregNoel>	garyo +1
 209 17:47:44 <sgk>	+1
 210 17:47:49 <GregNoel>	done
 211 17:47:57 <GregNoel>	2667
 212 17:48:05 <garyo>	2667: thanks Bill!
 213 17:48:11 <bdbaddog>	np.
 214 17:48:45 <GregNoel>	2668 same?
 215 17:48:28 <sgk>	also thanks bill
 216 17:48:32 <bdbaddog>	np
 217 17:48:46 <jason_at_intel>	Ya Bill :-)
 218 17:48:56 <GregNoel>	done
 219 17:49:03 <GregNoel>	2670
 220 17:49:21 <GregNoel>	consensus invalid
 221 17:49:30 <sgk>	invalid, close it (off the books) and invite reopen
 222 17:49:35 <sgk>	(2670 that is)
 223 17:49:37 <jason_at_intel>	Gary hit the main point
 224 17:49:52 <garyo>	But sometime I want to talk about why scons has to only build . by default... some other time.
 225 17:50:24 <sgk>	sure
 226 17:49:28 <GregNoel>	2671
 227 17:50:25 <garyo>	2671: I'll take that, integrate the patch & test.
 228 17:50:34 <sgk>	cool, thnx
 229 17:50:32 <GregNoel>	thanks; done
 230 17:51:06 <GregNoel>	2672 already discussed
 231 17:51:16 <GregNoel>	2114
 232 17:52:02 <garyo>	Agree we need to reassign... but who's doing any Fortran?
 233 17:52:32 <GregNoel>	This looks more like user error to me
 234 17:53:00 <GregNoel>	It's probably that bug where a missing tool will cause actions to change.
 235 17:53:03 <garyo>	Greg: that's one way to look at it.  But the suffix logic is overcomplicated too, which contributes.
 236 17:53:34 <GregNoel>	True, but that's where anonymous builders should come in.
 237 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.
 238 17:54:04 <garyo>	(or sth like that)
 239 17:54:03 <sgk>	there's a fair amount of diagnosis in the issue already
 240 17:54:34 <garyo>	I think it does eventually come down to "don't do it like that" though, not an actual bug.
 241 17:54:45 <GregNoel>	I'll not fight; a short-term fix is fine
 242 17:54:23 <sgk>	how about 2.x p4 sk?
 243 17:54:44 <garyo>	sgk: ok by me...
 244 17:55:07 <GregNoel>	2.x p4 sk is fine
 245 17:55:16 <sgk>	done
 246 17:55:17 <GregNoel>	consensus?
 247 17:55:25 <bdbaddog>	+1
 248 17:55:32 <jason_at_intel>	+1
 249 17:55:28 <GregNoel>	2128
 250 17:56:08 <sgk>	2128:  2.1 p3 sk (looks pretty quick)
 251 17:56:17 <garyo>	thanks
 252 17:56:19 <GregNoel>	done; thanks
 253 17:56:31 <GregNoel>	2249
 254 17:57:16 <GregNoel>	bypass?  There's only the one comment so it doesn't abide by the "two significant comments" rule.
 255 17:57:30 <sgk>	defer to next time
 256 17:57:33 <garyo>	relook next time
 257 17:57:36 <GregNoel>	done
 258 17:57:48 <jason_at_intel>	Thanks greg
 259 17:57:53 <sgk>	2485:  defer also?
 260 17:58:01 <garyo>	still working on 2485.  It's weird.
 261 17:58:10 <GregNoel>	defer or reassign to p2 or p3?
 262 17:58:40 <garyo>	Keep as p1 so we review next time.  I should have news by then.
 263 17:58:46 <GregNoel>	done
 264 17:59:01 <GregNoel>	2521?
 265 17:59:16 <GregNoel>	bypass?
 266 17:59:34 <bdbaddog>	sure. til next time.
 267 17:59:35 <sgk>	defer
 268 17:59:40 <GregNoel>	done
 269 17:59:52 <GregNoel>	2575 bypass?
 270 18:00:02 <sgk>	sure
 271 18:00:30 <GregNoel>	seeing no other response, done
 272 18:00:36 <GregNoel>	2630
 273 18:00:52 <GregNoel>	2.1 p1 Steven?
 274 18:01:03 <sgk>	worksforme
 275 18:01:07 <garyo>	thanks!
 276 18:01:21 <GregNoel>	Is it really a regression or should it be p2?
 277 18:01:48 <garyo>	Can't be a regression, this never worked with batch
 278 18:02:07 <GregNoel>	2.1 p2 then?
 279 18:02:14 <garyo>	+1
 280 18:02:20 <GregNoel>	done
 281 18:02:32 <GregNoel>	That's it for today; good work.
 282 18:02:42 <GregNoel>	I didn't think we were going to finish them all...
 283 18:02:44 <garyo>	agreed, thanks all
 284 18:02:49 <sgk>	good stuff
 285 18:02:55 <garyo>	We started slow, I was worried too :-)
 286 18:03:17 <garyo>	so who wants to talk about dvcs?
 287 18:03:18 <sgk>	bad traffic today, so i'll be on for awhile
 288 18:03:25 <bdbaddog>	+1 dvcs
 289 18:03:31 <sgk>	obviously people are free to go, but i'll stay and talk dvcs as long as i can
 290 18:04:03 <sgk>	bdbaddog:  thanks for weighing in on the email thread, the HOWTO list is a good start
 291 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.
 292 18:04:14 <sgk>	garyo:  msysgit on Windows?
 293 18:04:33 <garyo>	Yes, though a couple like tortoisegit.
 294 18:04:50 <garyo>	But we're going with hg, right?
 295 18:05:12 <garyo>	(or am I jumping the gun?)
 296 18:05:17 <jason_at_intel>	I really wish we are not going with GIT
 297 18:05:32 <jason_at_intel>	HG or bzr are more cross platform friendly
 298 18:05:45 <jason_at_intel>	and work with SVN
 299 18:05:58 <garyo>	I thought we'd all-but-decided hg, since it's python and is at least reasonable
 300 18:05:39 <sgk>	nah, it's time to just pick and make it happen and work the consequences
 301 18:06:07 <garyo>	sgk: agreed.  Pick one.
 302 18:06:04 <sgk>	fwiw, chrome team hasn't gotten msysgit to the point where they can really rely on it
 303 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
 304 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)
 305 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.
 306 18:07:14 <sgk>	garyo:  you've experimented w/hg, yes?
 307 18:07:25 <sgk>	(but not bzr)
 308 18:07:26 <garyo>	sgk: yes, it was reasonable.
 309 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?
 310 18:07:45 <sgk>	that's a key driver for me
 311 18:07:58 <garyo>	jason: yes, and local topic branches and better merging and so on.
 312 18:08:10 <sgk>	i've been switching back and forth between hg front-ending svn and svn, and dvcs is definitely more convenient
 313 18:08:23 <sgk>	okay, let's go with hg
 314 18:08:36 <sgk>	we have more experience amongst us with it thant bzar
 315 18:08:45 <garyo>	sgk: agreed.  It's python, it's reasonable.
 316 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
 317 18:09:17 <sgk>	yeah, hopefully
 318 18:09:32 <garyo>	I think it's easier in the long run
 319 18:08:43 <GregNoel>	Sounds good.  Where do we want to start?
 320 18:09:41 <garyo>	After 2.1 is out maybe?
 321 18:10:04 <garyo>	Or do you guys want to do it sooner?
 322 18:10:25 <sgk>	let's get 2.1 out and tackle it right after
 323 18:10:36 <sgk>	russel's argument for that timing was good
 324 18:09:58 <bdbaddog>	o.k. so google code hosting, bitbucket.org hosting, sourceforge, other?
 325 18:09:58 <sgk>	so far i've been finding the hg / svn interaction okay for normal work
 326 18:10:20 <garyo>	bdbaddog: are those the main hg choices?
 327 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?
 328 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.
 329 18:10:40 <sgk>	gives us a little time to plan, too
 330 18:10:53 <jason_at_intel>	or go with bit bucket and more stuff all there
 331 18:11:02 <garyo>	jason: don't forget the main scons.org site too ;-)
 332 18:11:15 <sgk>	jason_at_intel:  i think three sites is what we're looking at now
 333 18:11:24 <bdbaddog>	I don't see any reason to move all of them at the same time (bug, download, sources)
 334 18:11:34 <jason_at_intel>	yep .. so four sites total
 335 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.
 336 18:11:45 <sgk>	but we can at least decide now with an eye towards what looks like reasonable bug tracking
 337 18:12:14 <jason_at_intel>	Seems good... I just like to have a fewer sites long term
 338 18:11:35 <GregNoel>	Gary, is the Hg server by-demand or persistent?  Could we run it on scons.org?
 339 18:11:59 <sgk>	GregNoel:  ooh, good point
 340 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.
 341 18:12:42 <bdbaddog>	Yeah -100 on running it ourselves.
 342 18:12:57 <bdbaddog>	backups, operational issues not worth handling.
 343 18:13:15 <sgk>	good point
 344 18:12:15 <bdbaddog>	I'd sugguest just talking about DVCS, get that done, and then talk about the rest?
 345 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
 346 18:13:26 <garyo>	Android's hosted on google and seems OK, but let's do a little poking around before we choose.
 347 18:13:52 <sgk>	we already moved away from sourceforge once because of the bug tracking
 348 18:14:01 <sgk>	i'd probably veto going back unless it's improved significantly
 349 18:14:21 <garyo>	I remember the SF switch well :-/
 350 18:14:37 <GregNoel>	<shudder> so do I
 351 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.
 352 18:14:31 <sgk>	licenses for...?
 353 18:14:40 <sgk>	i.e. number of branches you can host?
 354 18:14:53 <garyo>	So sounds like we investigate google, bitbucket... and anything else?
 355 18:15:01 <bdbaddog>	source code licenses (GPL, MIT,etc..)
 356 18:15:35 <sgk>	we're MIT, so i'm pretty sure we're okay
 357 18:15:42 <bdbaddog>	k.
 358 18:15:46 <bdbaddog>	MIT's there. 99% sure.
 359 18:15:56 <loonycyborg>	googlecode supports hg FWIW
 360 18:16:13 <sgk>	any others to contemplate besides code.google.com and bitbucket?
 361 18:16:25 <loonycyborg>	Sourceforge :P
 362 18:16:36 <garyo>	Those were the only ones I recognized at http://mercurial.selenic.com/wiki/MercurialHosting
 363 18:17:01 <garyo>	... that seemed suitable for us, I mean.
 364 18:17:10 <sgk>	snark aside, has sourceforge gotten more reasonable lately (especially the bug tracker)?
 365 18:17:30 <bdbaddog>	nope. still junk.
 366 18:17:39 <GregNoel>	Not that I've seen.  I follow a project that still uses it and it's horrible.
 367 18:17:45 <loonycyborg>	FRS was improved somewhat.
 368 18:18:19 <loonycyborg>	FRS seems to be the only worthwhile thing about sourceforge.
 369 18:18:19 <jason_at_intel>	I agree... I like bitbucket more myself
 370 18:18:21 <bdbaddog>	so web based pull requests and forking are nice to have with DVCS's.
 371 18:18:35 <bdbaddog>	I've been using bitbucket for a personal project for a bit, seems o.k. to me.
 372 18:19:06 <jason_at_intel>	it seems to have a lot of stuff
 373 18:17:47 <sgk>	if they're not a strong contender, then let's not waste time evaluating them
 374 18:17:56 <bdbaddog>	yup. google or bitbucket.
 375 18:18:17 <garyo>	ok.  Post any findings to the dev ML and we'll regroup and decide.
 376 18:18:30 <sgk>	Mailing LIst, wiki page, or both?
 377 18:18:47 <bdbaddog>	wiki - yes
 378 18:19:02 <GregNoel>	sgk, we'll need a summary eventually, so should start now.
 379 18:19:19 <garyo>	Greg: I was going to disagree but that's a good point.
 380 18:19:24 <garyo>	So +1 on wiki.
 381 18:19:27 <sgk>	okay, wiki it is
 382 18:19:31 <sgk>	any volunteers to start the page?  I will unless someone else is eager
 383 18:19:55 <garyo>	Once it's started, don't forget to subscribe to it, everyone.
 384 18:20:02 <GregNoel>	... but still converse on dev list (or release list?)
 385 18:20:02 <sgk>	right
 386 18:20:35 <sgk>	i think we can play that a little by ear
 387 18:20:47 <sgk>	dev list for kicking around ideas
 388 18:21:02 <sgk>	wiki page for final decisions and opinions that you want made part of the public record
 389 18:21:06 <GregNoel>	play by ear makes sense.
 390 18:21:30 <garyo>	Has Russel(?) converted SCons to an hg repo?  Or did someone else?
 391 18:21:47 <sgk>	i think he has both a bzr and hg repo somewhere?
 392 18:22:07 <garyo>	That's good news, means our cutover may be smooth.
 393 18:22:18 <sgk>	i know he's a bug fan of bzr and Launchpad
 394 18:22:18 <sgk>	big
 395 18:22:28 <garyo>	yep
 396 18:22:33 <GregNoel>	or even a big bug fan...
 397 18:22:54 <jason_at_intel>	I believe there is a BZR and HG repro out there
 398 18:23:00 <sgk>	i'll probably start two pages, one to hold brainstorming on the task list (and sign up volunteers)
 399 18:23:10 <sgk>	and one to discuss pros + cons of code.google.com and bitbucket
 400 18:23:24 <garyo>	That sounds great
 401 18:23:37 <GregNoel>	sgk, you can use /Discussion pages for some of that.
 402 18:23:50 <sgk>	GregNoel:  good point
 403 18:23:35 <garyo>	ok, I think I'm going to sign off now & get some sleep.  This is all good progress & thought.
 404 18:23:36 <sgk>	(<1 minute to shuttle end)
 405 18:24:03 <sgk>	okay, gotta go -- thanks everyone, lot of good work tonight
 406 18:24:07 <garyo>	g'night
 407 18:24:12 <jason_at_intel>	well good night all.. till next time
 408 18:24:16 <GregNoel>	Looks like it's over tonight; g'night all.
 409 18:24:20 *	sgk (~sgk@67.218.110.174) has left #SCONS
 410 18:24:26 *	garyo (~garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has left #SCONS
 411 18:24:33 *	jason_at_intel has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.6/20100625231939])
 412 18:44:15 *	loonycyborg has quit (Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz)
 413 21:13:39 *	bdbaddog has quit (Read error: Connection reset by peer)
 414 

BugParty/IrcLog2010-08-03 (last edited 2010-08-07 08:12:51 by ip68-7-79-188)