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: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)