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
