-
-
Notifications
You must be signed in to change notification settings - Fork 315
IrcLog2010 08 03
William Deegan edited this page Jan 14, 2016
·
2 revisions
16:41:49 * jason_at_intel (~[[email protected]](mailto:[email protected])) has joined #SCONS
16:45:32 * garyo (~[[email protected]](mailto:[email protected])) has joined #SCONS
17:00:22 * [GregNoel](GregNoel) has arrived and is setting up
17:01:03 * bdbaddog (~[[email protected]](mailto:[email protected])) has joined #SCONS
17:01:57 <[GregNoel](GregNoel)> I don't see Steven, but it looks like a pretty full house. Sergey, are you there?
17:02:10 <loonycyborg> Yes.
17:02:14 <garyo> Hi Sergey!
17:02:23 <loonycyborg> Hello.
17:02:23 <[GregNoel](GregNoel)> Are we ready to start?
17:02:40 <garyo> I think so
17:02:41 <jason_at_intel> I am ready
17:02:45 <jason_at_intel> are we going to wait for steven?
17:02:56 <[GregNoel](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...
17:03:39 <garyo> mingw cmd line?
17:03:50 <loonycyborg> That guy had trouble linking libraries due to inherent limit on length of command lines in windows.
17:03:54 <jason_at_intel> Is that not a dup of [TempFileMunge](TempFileMunge) bug?
17:05:25 <loonycyborg> That [TempFileMunge](TempFileMunge) thingy doesn't seem to be used for mingw at all.
17:05:37 <jason_at_intel> Yep
17:05:52 <loonycyborg> Probably because mingw gcc < 4 doesn't support the @ indirection.
17:05:59 <jason_at_intel> I just looked.. there is no use of TEMPFILE in the tool
17:06:11 <jason_at_intel> this would have to be added to the tool, so it could be used
17:06:31 <jason_at_intel> what does it support?
17:06:41 <jason_at_intel> I believe the tempfile does not have to use @
17:07:00 <garyo> jason: gcc didn't used to support any kind of cmd files iirc.
17:07:02 <loonycyborg> What else can it do?
17:07:35 <jason_at_intel> does it work if you add the full command to the a batch file?
17:07:51 <jason_at_intel> grasping at straws here ...
17:08:13 <garyo> Sergey: if >=4.0 works could we just use tempfile in that case?
17:08:36 <[GregNoel](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.
17:09:07 <loonycyborg> Probably yes. For lesser limits. There also are some in the shell iirc.
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.
17:09:33 * sgk (~sgk@nat/google/x-gafuxkitacszsdsy) has joined #SCONS
17:09:40 <sgk> anyone still here?
17:09:42 <jason_at_intel> hi Steve!
17:09:48 <garyo> Hi Steven
17:09:49 <[GregNoel](GregNoel)> No, we've all left.
17:09:52 <sgk> sorry I'm later, got caught up debugging
17:10:02 <sgk> unfortunately, i still have to hike over to the shuttle
17:10:29 <loonycyborg> The standard practice is to build those objects into intermediate archives so command lines do not break the limit.
17:10:41 <loonycyborg> Perhaps scons could automate this somehow.
17:10:56 <sgk> (what number are we on?)
17:10:54 <garyo> sgk: we're talking about 2672, mingw line length limit
17:11:17 <bdbaddog> 2672
17:11:26 <jason_at_intel> we jumped to 2672
17:10:58 <sgk> thx
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
17:11:44 <garyo> (i.e. just document it)
17:12:06 <loonycyborg> It would be nice to abstract those details.
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?
17:12:18 <loonycyborg> Would help with portability.
17:12:40 * sgk searches for the one he thought it was a dup of
17:12:45 <[GregNoel](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.
17:12:46 <bdbaddog> can you specify the file as - and feed it stdout ?
17:12:49 <garyo> I'd be upset if my build tool suddenly built half my objects into a temp archive.
17:13:14 <sgk> [http://scons.tigris.org/issues/show_bug.cgi?id=2628](http://scons.tigris.org/issues/show_bug.cgi?id=2628)
17:13:25 <garyo> but the portability point is a good one, I admit
17:13:38 <sgk> not a dup of the specific circumstance (2628 puts it in the context of batch building)
17:13:48 <sgk> but now that i saw 2672, i think it's the general problem
17:14:15 <sgk> 2628 has a code snippet that wraps shared object command lines with $(TEMPFILE{} by hand
17:14:11 <garyo> sgk: it's different because mingw doesn't support @ file indirection, so TEMPFILE doesn't work at all.
17:14:21 <sgk> aha
17:14:33 <sgk> okay, don't mind me... :-)
17:14:34 <loonycyborg> It does support it starting at gcc4
17:15:26 <jason_at_intel> so with gcc 4.1o there is @ support
17:15:31 <jason_at_intel> 4.1.0
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.
17:16:23 <jason_at_intel> I agree with gary
17:16:51 <garyo> anyone object?
17:16:55 <jason_at_intel> but we would want to make the limit around 8K not 1K as it is in [TempFile](TempFile) currently to reduce risk
17:17:11 <[GregNoel](GregNoel)> Is there a decision?
17:17:13 <garyo> good point, Jason.
17:17:24 <sgk> k, i'll be back in ~6-8 minutes
17:17:27 * sgk has quit (Quit: sgk)
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.
17:18:01 <jason_at_intel> Add tempFile.. and make the limit it uses to 8K for the ming tool
17:18:15 <garyo> Sergey, what do you think?
17:18:17 <loonycyborg> [GregNoel](GregNoel): TEMPFILE could still help with 8K limit.
17:19:05 <loonycyborg> 32K not so much because mingw does call ld commands that do break the limit too.
17:19:18 <[GregNoel](GregNoel)> loonycyborg, I'm a Unix weenie, so I don't even know what a TEMPFILE does, much less what the limits are.
17:20:00 <jason_at_intel> the cmd.exe has a 8K limit for stuff it passes on the Commandline
17:20:10 <[GregNoel](GregNoel)> ... And I don't care.
17:20:13 <garyo> ok, so 2672, loonycyborg, 2.?, p?
17:20:45 <garyo> (Do'nt mean to sign you up unless you're OK w/ it, Sergey)
17:20:33 <jason_at_intel> so tempfile make a file that the exe can read to get really long commandlines
17:21:03 <jason_at_intel> it seem gcc has it own limit however that can break on linux
17:21:12 <jason_at_intel> that is why the @ option was added
17:21:26 <jason_at_intel> not a linux bug but a gcc one
17:21:51 <garyo> I suggest 2.2 p3 unless Sergey (or whoever) has time to do it for 2.1
17:22:15 <jason_at_intel> +1
17:22:20 <loonycyborg> Strictly speaking I can't do anything since I don't have commit access :P
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)
17:23:52 <garyo> ... crickets ...
17:24:16 <bdbaddog> no mingw here.
17:24:19 <garyo> so are we done with this one? :-)
17:24:30 <bdbaddog> +1 on done
17:24:31 <loonycyborg> I have several mingw setups, so I'll look into it..
17:24:43 <[GregNoel](GregNoel)> done
17:25:00 <garyo> great. Sergey, reassign to me when you've got the patch.
17:25:26 <[GregNoel](GregNoel)> (Thanks Sergey)
17:26:45 <loonycyborg> Though I'm surprised that noone else here has a mingw setup.
17:27:05 <loonycyborg> [http://nuwen.net/mingw.html](http://nuwen.net/mingw.html) <- that mingw distro is easy to deploy.
17:27:32 <garyo> loonycyborg: I should try it. I mostly use cygwin tools on windows, but Intel compiler.
17:27:33 <jason_at_intel> I had one... but i have no need to use it.. I have free window compiler
17:25:01 <[GregNoel](GregNoel)> moving on to 2629
17:25:02 <jason_at_intel> 2629?
17:25:49 <garyo> 2629: defer till sgk is back online?
17:25:59 <jason_at_intel> +1
17:26:18 <garyo> 2671 then
17:26:47 * sgk (~[[email protected]](mailto:[email protected])) has joined #SCONS
17:27:03 <[GregNoel](GregNoel)> Speaking of the devil...
17:27:06 <sgk> hello again
17:27:07 <garyo> Sigh, I'll take 2671 to test and commit it. Make it p3 though.
17:27:31 <[GregNoel](GregNoel)> works for me; thanks.
17:28:13 <garyo> So back to 2629 now that sgk is back...
17:28:21 <[GregNoel](GregNoel)> Back to 2629?
17:28:37 <sgk> k
17:28:46 <sgk> 2.1 p1 sk is my vote
17:28:55 <[GregNoel](GregNoel)> done
17:29:00 <sgk> i should have filled in owner
17:29:11 <garyo> +1, thanks Steven
17:29:11 <[GregNoel](GregNoel)> 2650?
17:29:38 <garyo> no prob if it's delayed. Mark as research p4 and we'll get to it when you're ready.
17:29:39 <jason_at_intel> what is SEP
17:29:45 <garyo> Scons Enhancement Proposal
17:29:55 <garyo> (see the wiki)
17:29:57 <jason_at_intel> ahh DUH :-)
17:29:46 <[GregNoel](GregNoel)> done
17:29:55 <[GregNoel](GregNoel)> 2664?
17:30:39 <bdbaddog> I'll take it.
17:30:41 <sgk> go bill
17:30:46 <garyo> yay
17:31:00 <sgk> many thnx
17:30:55 <[GregNoel](GregNoel)> research p3?
17:31:25 <sgk> research p3 feels right to me
17:31:30 <[GregNoel](GregNoel)> done
17:31:37 <[GregNoel](GregNoel)> 2665?
17:31:56 <sgk> i guess the key question is whether we want this sort of thing to "Just Work"
17:31:58 <garyo> Greg: are you sure we don't escape special chars in filenames?
17:32:24 <[GregNoel](GregNoel)> garyo, not absolutely positive, but I believe so.
17:32:14 <sgk> we don't
17:32:19 <sgk> or rather
17:32:29 <sgk> we kind of do some, but not well
17:32:53 <garyo> ok, so it sounds invalid then (except maybe for the space one, spaces are kinda important these days)
17:33:06 <[GregNoel](GregNoel)> Steven has it right. There's an escape() function defined, but it doesn't do all that much.
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\(\)
17:33:37 <sgk> with the backslashes in the file name
17:33:44 <sgk> so something somewhere did try to escape those
17:33:45 <jason_at_intel> is that what is used in the SPAWN functions?
17:34:15 <sgk> i personally like the idea that all of this gets cleaned up and supported by using subprocess
17:34:21 <sgk> am i dreaming?
17:34:36 <bdbaddog> sounds like a good dream to me.. ;)
17:34:59 <jason_at_intel> nope.. I though we are to look at this when i visit?
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.
17:35:10 <jason_at_intel> see what i had done.. and see what is needed to make it work in SCOns
17:35:21 <garyo> +1
17:35:34 <sgk> so do we keep 2665 around to document the test case?
17:35:35 <[GregNoel](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.
17:35:50 <sgk> smarter than we are, anyway... :-)
17:36:22 <jason_at_intel> It is... You can use the escape function with subprocess
17:36:28 <jason_at_intel> it will make the call fail
17:36:35 <garyo> either keep 2665 around or close as invalid and capture testcase elsewhere
17:36:44 <sgk> i had an idea about issues like this with good future test cases
17:36:44 <jason_at_intel> just saying from experience on this one
17:37:07 <sgk> what if we checked in the test case as a skipped test?
17:37:41 <sgk> with some message like "TODO: issue 2661" or some such
17:38:00 <[GregNoel](GregNoel)> I did that for a couple of the cases I converted into deprecated since I didn't have the tools to test it.
17:37:26 <garyo> good idea
17:37:57 <garyo> the only hard part is remembering it's there, and un-skipping it when the time's right.
17:38:01 <sgk> they could be in a separate test/pending subdirectory
17:38:23 <[GregNoel](GregNoel)> sgk, that works.
17:38:54 <sgk> k, well let's add that to the mental toolbox of ways to handle issues
17:39:05 <sgk> since i suggested it, i can be the stuckee for that
17:39:10 <garyo> thanks!
17:39:37 <sgk> give me 2665, say, 2.x p4? and I'll capture the test case
17:39:47 <sgk> do we have a "subprocess" or similar keyword for issues?
17:39:48 <[GregNoel](GregNoel)> so 2665 sk to capture test, then mark invalid?
17:40:57 * [GregNoel](GregNoel) is checking if there's a 'subprocess' keyword
17:40:29 <sgk> i can go either way
17:40:43 <sgk> invalid (with an explanation) if we just want to get it off the books
17:41:08 <[GregNoel](GregNoel)> get it off the books.
17:41:47 <sgk> ok by me
17:42:06 <sgk> I'll track down a recommended workaround and update the issue with it when i close it
17:42:20 <sgk> plus explain that we're checking in the test case for future
17:42:16 <garyo> perfect
17:41:43 <garyo> Don't we also have a quoting keyword or something like that?
17:43:12 <[GregNoel](GregNoel)> sgk, no subprocess keyword, garyo, use 'subst'
17:44:06 <garyo> Anyway sgk's going to close 2665 so keyword doesn't matter
17:42:55 <garyo> 2666?
17:43:22 <sgk> 3.0 feels right to me because of the incompatibility
17:43:52 <sgk> (bdbaddog: this is an inconsistency with what's in [CacheDir](CacheDir), not what's in .sconsign)
17:44:01 <bdbaddog> SGK: gotcha
17:44:04 <jason_at_intel> so is a false rebuild once on windows that big of an issue?
17:45:05 <jason_at_intel> besides you have to delete the directory every so often as it just grows
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
17:45:14 <garyo> Jason: we have treated it that way in the past.
17:45:52 <jason_at_intel> I am not against it... I just don't see it as a big deal
17:46:06 <sgk> yeah, it not being a big deal also pushes it to 3.0 for me
17:46:07 <jason_at_intel> Changes to builder have similar effects
17:46:13 <garyo> We could always make it optional now, then flip the switch in 3.0
17:46:50 <[GregNoel](GregNoel)> garyo, not a bad idea, but a lot of work.
17:47:09 <garyo> Greg: probably right. Just throwing it out there.
17:46:34 <jason_at_intel> so most people expect a small rebuild when updating SCons
17:46:45 <sgk> it feels like a corner case (pulling out the same generated files across platforms) that isn't burning anybody down
17:47:16 <sgk> more than seems worth it given the small subset of people likely affected
17:47:18 <jason_at_intel> A switch is always safe
17:47:29 <garyo> So we're agreed 3.0 p3/p4?
17:47:36 <bdbaddog> +1
17:47:38 <[GregNoel](GregNoel)> garyo +1
17:47:44 <sgk> +1
17:47:49 <[GregNoel](GregNoel)> done
17:47:57 <[GregNoel](GregNoel)> 2667
17:48:05 <garyo> 2667: thanks Bill!
17:48:11 <bdbaddog> np.
17:48:45 <[GregNoel](GregNoel)> 2668 same?
17:48:28 <sgk> also thanks bill
17:48:32 <bdbaddog> np
17:48:46 <jason_at_intel> Ya Bill :-)
17:48:56 <[GregNoel](GregNoel)> done
17:49:03 <[GregNoel](GregNoel)> 2670
17:49:21 <[GregNoel](GregNoel)> consensus invalid
17:49:30 <sgk> invalid, close it (off the books) and invite reopen
17:49:35 <sgk> (2670 that is)
17:49:37 <jason_at_intel> Gary hit the main point
17:49:52 <garyo> But sometime I want to talk about why scons has to only build . by default... some other time.
17:50:24 <sgk> sure
17:49:28 <[GregNoel](GregNoel)> 2671
17:50:25 <garyo> 2671: I'll take that, integrate the patch & test.
17:50:34 <sgk> cool, thnx
17:50:32 <[GregNoel](GregNoel)> thanks; done
17:51:06 <[GregNoel](GregNoel)> 2672 already discussed
17:51:16 <[GregNoel](GregNoel)> 2114
17:52:02 <garyo> Agree we need to reassign... but who's doing any Fortran?
17:52:32 <[GregNoel](GregNoel)> This looks more like user error to me
17:53:00 <[GregNoel](GregNoel)> It's probably that bug where a missing tool will cause actions to change.
17:53:03 <garyo> Greg: that's one way to look at it. But the suffix logic is overcomplicated too, which contributes.
17:53:34 <[GregNoel](GregNoel)> True, but that's where anonymous builders should come in.
17:53:51 <garyo> I just looked at it. The user sets FORTRANFILESUFFIXES, then in [FortranCommon](FortranCommon).py the generate function turns that into FORTRANSUFFIXES. So if you set FORTRANFILESUFFIXES later it has no effect.
17:54:04 <garyo> (or sth like that)
17:54:03 <sgk> there's a fair amount of diagnosis in the issue already
17:54:34 <garyo> I think it does eventually come down to "don't do it like that" though, not an actual bug.
17:54:45 <[GregNoel](GregNoel)> I'll not fight; a short-term fix is fine
17:54:23 <sgk> how about 2.x p4 sk?
17:54:44 <garyo> sgk: ok by me...
17:55:07 <[GregNoel](GregNoel)> 2.x p4 sk is fine
17:55:16 <sgk> done
17:55:17 <[GregNoel](GregNoel)> consensus?
17:55:25 <bdbaddog> +1
17:55:32 <jason_at_intel> +1
17:55:28 <[GregNoel](GregNoel)> 2128
17:56:08 <sgk> 2128: 2.1 p3 sk (looks pretty quick)
17:56:17 <garyo> thanks
17:56:19 <[GregNoel](GregNoel)> done; thanks
17:56:31 <[GregNoel](GregNoel)> 2249
17:57:16 <[GregNoel](GregNoel)> bypass? There's only the one comment so it doesn't abide by the "two significant comments" rule.
17:57:30 <sgk> defer to next time
17:57:33 <garyo> relook next time
17:57:36 <[GregNoel](GregNoel)> done
17:57:48 <jason_at_intel> Thanks greg
17:57:53 <sgk> 2485: defer also?
17:58:01 <garyo> still working on 2485. It's weird.
17:58:10 <[GregNoel](GregNoel)> defer or reassign to p2 or p3?
17:58:40 <garyo> Keep as p1 so we review next time. I should have news by then.
17:58:46 <[GregNoel](GregNoel)> done
17:59:01 <[GregNoel](GregNoel)> 2521?
17:59:16 <[GregNoel](GregNoel)> bypass?
17:59:34 <bdbaddog> sure. til next time.
17:59:35 <sgk> defer
17:59:40 <[GregNoel](GregNoel)> done
17:59:52 <[GregNoel](GregNoel)> 2575 bypass?
18:00:02 <sgk> sure
18:00:30 <[GregNoel](GregNoel)> seeing no other response, done
18:00:36 <[GregNoel](GregNoel)> 2630
18:00:52 <[GregNoel](GregNoel)> 2.1 p1 Steven?
18:01:03 <sgk> worksforme
18:01:07 <garyo> thanks!
18:01:21 <[GregNoel](GregNoel)> Is it really a regression or should it be p2?
18:01:48 <garyo> Can't be a regression, this never worked with batch
18:02:07 <[GregNoel](GregNoel)> 2.1 p2 then?
18:02:14 <garyo> +1
18:02:20 <[GregNoel](GregNoel)> done
18:02:32 <[GregNoel](GregNoel)> That's it for today; good work.
18:02:42 <[GregNoel](GregNoel)> I didn't think we were going to finish them all...
18:02:44 <garyo> agreed, thanks all
18:02:49 <sgk> good stuff
18:02:55 <garyo> We started slow, I was worried too :-)
18:03:17 <garyo> so who wants to talk about dvcs?
18:03:18 <sgk> bad traffic today, so i'll be on for awhile
18:03:25 <bdbaddog> +1 dvcs
18:03:31 <sgk> obviously people are free to go, but i'll stay and talk dvcs as long as i can
18:04:03 <sgk> bdbaddog: thanks for weighing in on the email thread, the HOWTO list is a good start
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.
18:04:14 <sgk> garyo: msysgit on Windows?
18:04:33 <garyo> Yes, though a couple like tortoisegit.
18:04:50 <garyo> But we're going with hg, right?
18:05:12 <garyo> (or am I jumping the gun?)
18:05:17 <jason_at_intel> I really wish we are not going with GIT
18:05:32 <jason_at_intel> HG or bzr are more cross platform friendly
18:05:45 <jason_at_intel> and work with SVN
18:05:58 <garyo> I thought we'd all-but-decided hg, since it's python and is at least reasonable
18:05:39 <sgk> nah, it's time to just pick and make it happen and work the consequences
18:06:07 <garyo> sgk: agreed. Pick one.
18:06:04 <sgk> fwiw, chrome team hasn't gotten msysgit to the point where they can really rely on it
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
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)
18:07:05 <[GregNoel](GregNoel)> Sorry, I was called away for a bit. I like Hg as it's scriptable in Python, but otherwise I don't care.
18:07:14 <sgk> garyo: you've experimented w/hg, yes?
18:07:25 <sgk> (but not bzr)
18:07:26 <garyo> sgk: yes, it was reasonable.
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?
18:07:45 <sgk> that's a key driver for me
18:07:58 <garyo> jason: yes, and local topic branches and better merging and so on.
18:08:10 <sgk> i've been switching back and forth between hg front-ending svn and svn, and dvcs is definitely more convenient
18:08:23 <sgk> okay, let's go with hg
18:08:36 <sgk> we have more experience amongst us with it thant bzar
18:08:45 <garyo> sgk: agreed. It's python, it's reasonable.
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
18:09:17 <sgk> yeah, hopefully
18:09:32 <garyo> I think it's easier in the long run
18:08:43 <[GregNoel](GregNoel)> Sounds good. Where do we want to start?
18:09:41 <garyo> After 2.1 is out maybe?
18:10:04 <garyo> Or do you guys want to do it sooner?
18:10:25 <sgk> let's get 2.1 out and tackle it right after
18:10:36 <sgk> russel's argument for that timing was good
18:09:58 <bdbaddog> o.k. so google code hosting, bitbucket.org hosting, sourceforge, other?
18:09:58 <sgk> so far i've been finding the hg / svn interaction okay for normal work
18:10:20 <garyo> bdbaddog: are those the main hg choices?
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?
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.
18:10:40 <sgk> gives us a little time to plan, too
18:10:53 <jason_at_intel> or go with bit bucket and more stuff all there
18:11:02 <garyo> jason: don't forget the main scons.org site too ;-)
18:11:15 <sgk> jason_at_intel: i think three sites is what we're looking at now
18:11:24 <bdbaddog> I don't see any reason to move all of them at the same time (bug, download, sources)
18:11:34 <jason_at_intel> yep .. so four sites total
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.
18:11:45 <sgk> but we can at least decide now with an eye towards what looks like reasonable bug tracking
18:12:14 <jason_at_intel> Seems good... I just like to have a fewer sites long term
18:11:35 <[GregNoel](GregNoel)> Gary, is the Hg server by-demand or persistent? Could we run it on scons.org?
18:11:59 <sgk> [GregNoel](GregNoel): ooh, good point
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.
18:12:42 <bdbaddog> Yeah -100 on running it ourselves.
18:12:57 <bdbaddog> backups, operational issues not worth handling.
18:13:15 <sgk> good point
18:12:15 <bdbaddog> I'd sugguest just talking about DVCS, get that done, and then talk about the rest?
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
18:13:26 <garyo> Android's hosted on google and seems OK, but let's do a little poking around before we choose.
18:13:52 <sgk> we already moved away from sourceforge once because of the bug tracking
18:14:01 <sgk> i'd probably veto going back unless it's improved significantly
18:14:21 <garyo> I remember the SF switch well :-/
18:14:37 <[GregNoel](GregNoel)> <shudder> so do I
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.
18:14:31 <sgk> licenses for...?
18:14:40 <sgk> i.e. number of branches you can host?
18:14:53 <garyo> So sounds like we investigate google, bitbucket... and anything else?
18:15:01 <bdbaddog> source code licenses (GPL, MIT,etc..)
18:15:35 <sgk> we're MIT, so i'm pretty sure we're okay
18:15:42 <bdbaddog> k.
18:15:46 <bdbaddog> MIT's there. 99% sure.
18:15:56 <loonycyborg> googlecode supports hg FWIW
18:16:13 <sgk> any others to contemplate besides code.google.com and bitbucket?
18:16:25 <loonycyborg> Sourceforge :P
18:16:36 <garyo> Those were the only ones I recognized at [http://mercurial.selenic.com/wiki/MercurialHosting](http://mercurial.selenic.com/wiki/MercurialHosting)
18:17:01 <garyo> ... that seemed suitable for us, I mean.
18:17:10 <sgk> snark aside, has sourceforge gotten more reasonable lately (especially the bug tracker)?
18:17:30 <bdbaddog> nope. still junk.
18:17:39 <[GregNoel](GregNoel)> Not that I've seen. I follow a project that still uses it and it's horrible.
18:17:45 <loonycyborg> FRS was improved somewhat.
18:18:19 <loonycyborg> FRS seems to be the only worthwhile thing about sourceforge.
18:18:19 <jason_at_intel> I agree... I like bitbucket more myself
18:18:21 <bdbaddog> so web based pull requests and forking are nice to have with DVCS's.
18:18:35 <bdbaddog> I've been using bitbucket for a personal project for a bit, seems o.k. to me.
18:19:06 <jason_at_intel> it seems to have a lot of stuff
18:17:47 <sgk> if they're not a strong contender, then let's not waste time evaluating them
18:17:56 <bdbaddog> yup. google or bitbucket.
18:18:17 <garyo> ok. Post any findings to the dev ML and we'll regroup and decide.
18:18:30 <sgk> Mailing LIst, wiki page, or both?
18:18:47 <bdbaddog> wiki - yes
18:19:02 <[GregNoel](GregNoel)> sgk, we'll need a summary eventually, so should start now.
18:19:19 <garyo> Greg: I was going to disagree but that's a good point.
18:19:24 <garyo> So +1 on wiki.
18:19:27 <sgk> okay, wiki it is
18:19:31 <sgk> any volunteers to start the page? I will unless someone else is eager
18:19:55 <garyo> Once it's started, don't forget to subscribe to it, everyone.
18:20:02 <[GregNoel](GregNoel)> ... but still converse on dev list (or release list?)
18:20:02 <sgk> right
18:20:35 <sgk> i think we can play that a little by ear
18:20:47 <sgk> dev list for kicking around ideas
18:21:02 <sgk> wiki page for final decisions and opinions that you want made part of the public record
18:21:06 <[GregNoel](GregNoel)> play by ear makes sense.
18:21:30 <garyo> Has Russel(?) converted SCons to an hg repo? Or did someone else?
18:21:47 <sgk> i think he has both a bzr and hg repo somewhere?
18:22:07 <garyo> That's good news, means our cutover may be smooth.
18:22:18 <sgk> i know he's a bug fan of bzr and Launchpad
18:22:18 <sgk> big
18:22:28 <garyo> yep
18:22:33 <[GregNoel](GregNoel)> or even a big bug fan...
18:22:54 <jason_at_intel> I believe there is a BZR and HG repro out there
18:23:00 <sgk> i'll probably start two pages, one to hold brainstorming on the task list (and sign up volunteers)
18:23:10 <sgk> and one to discuss pros + cons of code.google.com and bitbucket
18:23:24 <garyo> That sounds great
18:23:37 <[GregNoel](GregNoel)> sgk, you can use /Discussion pages for some of that.
18:23:50 <sgk> [GregNoel](GregNoel): good point
18:23:35 <garyo> ok, I think I'm going to sign off now & get some sleep. This is all good progress & thought.
18:23:36 <sgk> (<1 minute to shuttle end)
18:24:03 <sgk> okay, gotta go -- thanks everyone, lot of good work tonight
18:24:07 <garyo> g'night
18:24:12 <jason_at_intel> well good night all.. till next time
18:24:16 <[GregNoel](GregNoel)> Looks like it's over tonight; g'night all.
18:24:20 * sgk (~[[email protected]](mailto:[email protected])) has left #SCONS
18:24:26 * garyo (~[[email protected]](mailto:[email protected])) has left #SCONS
18:24:33 * jason_at_intel has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.6.6/20100625231939])
18:44:15 * loonycyborg has quit (Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz)
21:13:39 * bdbaddog has quit (Read error: Connection reset by peer)