1 16:03:04 * techtonik (~chatzilla@mm-127-247-57-86.leased.line.mgts.by) has joined #SCONS
2 16:31:51 * garyo (~garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS
3 16:47:50 * bdbaddog (~chatzilla@207.88.181.2.ptr.us.xo.net) has joined #SCONS
4 17:00:39 * sgk (~sgk@nat/google/x-bfuzncsvocbkaddk) has joined #SCONS
5 17:00:48 <garyo> Hi guys
6 17:00:53 * You are no longer marked as being away
7 17:00:53 <sgk> hello hello
8 17:00:57 * GregNoel is here
9 17:01:07 <garyo> Hi Greg
10 17:01:14 <GregNoel> Hello, everyone; who all is here?
11 17:01:29 * sgk applauds GregNoel for getting 2.0.0 release
12 17:01:30 <garyo> Looks like me, sgk, Bill, you
13 17:01:32 <sgk> d
14 17:01:36 <bdbaddog> I'm here.
15 17:01:58 * Jason_at_Intel (~chatzilla@12.18.240.224) has joined #SCONS
16 17:02:00 <garyo> Yes -- kudos to both Greg and Bill for getting through a lot of checkpoints and releases recently!
17 17:02:04 <garyo> Hi Jason
18 17:02:15 <bdbaddog> Garyo: Thanks.
19 17:02:17 <Jason_at_Intel> HI all
20 17:02:34 <bdbaddog> I guess 1.3.1 should go out soon. I'll get it done when I'm back from this conference.
21 17:02:20 <GregNoel> sgk, garyo, thanks. We had a major earthquake leading to lots of network outages that made the process interesting...
22 17:02:29 <sgk> yow
23 17:02:37 <garyo> Oh yeah, I heard about that -- no major damage though?
24 17:03:10 <GregNoel> garyo, not to us. A picture fell off a shelf and broke the glass.
25 17:03:24 <Jason_at_Intel> ?
26 17:03:37 <garyo> I thought people in California didn't put things on shelves :-/
27 17:03:45 <garyo> (earthquake, Jason)
28 17:03:55 <Jason_at_Intel> ahh
29 17:04:07 <GregNoel> There are bookcases in our library.
30 17:04:32 <garyo> So wow, 2.0 is out and all kinds of stuff is now unblocked -- meaning I have to get to all those things I said I'd do post 2.0! :-) :-)
31 17:04:30 <GregNoel> Anyway, are we ready to go?
32 17:04:36 <garyo> Yes, I'm ready.
33 17:04:41 <sgk> ready
34 17:04:46 <GregNoel> 2634, wontfix?
35 17:05:03 <sgk> i can go there
36 17:05:05 <garyo> I'm ok w/ that, he'll reopen if needed
37 17:05:14 <GregNoel> done
38 17:05:16 <GregNoel> 2636, more time?
39 17:05:20 <garyo> yes
40 17:05:34 <sgk> yes, revisit next bug party
41 17:05:43 <GregNoel> done
42 17:05:45 <GregNoel> 2639, consensus 2.1 p3, but needs an owner.
43 17:05:54 <sgk> russel brought it up, right?
44 17:06:21 * sgk wishes that tigris.org's bug tracker had keyboard shortcuts
45 17:06:30 <GregNoel> {;-}
46 17:06:33 <Jason_at_Intel> loading spreadsheet.. but ready
47 17:06:35 <garyo> Maybe he'd do it. Yes, he posted it.
48 17:06:53 <garyo> no wait, Steven did.
49 17:07:33 <sgk> yeah, i opened it to avoid another N emails where people debated whether or not an issue should be opened, and by whom
50 17:06:53 <GregNoel> Or how about techtonik? He's interested in documentation.
51 17:07:00 <garyo> Greg: that's a good idea.
52 17:07:27 <Jason_at_Intel> anyone use the tiris ecplise of VS integration?
53 17:07:54 <garyo> jason: not me.
54 17:08:06 <sgk> if techtonik is interested, great
55 17:08:13 <garyo> OK, for 2639, assign to techtonik & see if he minds?
56 17:08:19 <garyo> Or ask first?
57 17:08:27 <GregNoel> OK, I'll ask him. Is that the decision?
58 17:08:32 <sgk> yeah
59 17:08:33 <garyo> +1 from me
60 17:08:45 <sgk> and if he doesn't want it, then i'm okay with just giving it to Russel
61 17:08:36 <GregNoel> done
62 17:08:39 <GregNoel> 2640, consensus 2.1 p2 Greg, unless Gary restores his offer... {;-}
63 17:08:39 <GregNoel> 2642, consensus 2.1 p3 Gary
64 17:08:39 <GregNoel> 2643, consensus 2.x p3 Gary (I'm neutral about coercion v. error)
65 17:08:39 <GregNoel> 2644, Steven, I don't think an organized text file is more of a custom file format than a "standard" XML binary format; quite the reverse, in fact. Besides, I'm leery of requiring another external package to diff XML when all the python versions we support have difflib for text.
66 17:09:23 <sgk> re: 2644: okay, suit yourself
67 17:09:26 <garyo> 2644, I don't have an opinion either way
68 17:10:36 <bdbaddog> +1 on not requiring more packages for developer.
69 17:10:32 <garyo> 2645 I can do, if you don't mind me doing it blind (no Fortran) -- I'll just check with the OP.
70 17:10:33 <GregNoel> 2645, consensus 2.1 p2, but needs an owner.
71 17:11:01 <garyo> I'll take it
72 17:11:30 <GregNoel> done
73 17:11:33 <GregNoel> 2646, consensus invalid
74 17:11:33 <GregNoel> 2647, Steven solved a nasty problem and checked in a fix, but should that fix be scheduled toward a release of 2.0.0.final.1, 2.0.1, or 2.1? I added a workaround to the issue that should work (Gary's suggestion of SideEffect() works perfectly), so if we deem that good, I vote for 2.1.
75 17:11:59 <sgk> what's the difference between 2.0.0.final.1 and 2.0.1 ?
76 17:12:02 <sgk> from a user perspective
77 17:12:21 <GregNoel> sgk, the former is a patch, the latter is a new release.
78 17:12:41 <sgk> and users need to know / care about that distinction because...?
79 17:12:01 <bdbaddog> Sideffect() is a workaround for the issue right?
80 17:12:15 <Jason_at_Intel> yep
81 17:12:09 <garyo> I vote for 2.1. It's still a corner case.
82 17:12:46 <Jason_at_Intel> Well as a corner case i can't promote to Scons 1.2+ till it is in
83 17:12:48 <bdbaddog> post bugs, I think we need to discuss getting rid of the .final.
84 17:12:50 <garyo> Right, we shouldn't drop everything to release this fix basically.
85 17:12:56 <GregNoel> I'm seeing a consensus toward 2.1
86 17:12:59 <Jason_at_Intel> I have six products that broke cause of this
87 17:13:16 <bdbaddog> it's a regression right?
88 17:13:21 <sgk> yes, it worked in 1.2.0
89 17:13:22 <bdbaddog> 2.0.1
90 17:13:25 <Jason_at_Intel> yep
91 17:13:26 <GregNoel> Jason_at_Intel, can you use SideEffect()?
92 17:13:27 <garyo> Hm, ok maybe it's an edge rather than a corner? :-)
93 17:13:34 <sgk> heh
94 17:13:47 <bdbaddog> we have a fix. 2.0.1, unless u think the fix might destability 2.0.0
95 17:13:56 <bdbaddog> destabilize that should be.
96 17:14:12 <Jason_at_Intel> Yes, i have people moving to it... but politics prevent a move to 2.0 cause of fear that something else if wrong
97 17:14:22 <garyo> I'm ok either way, just trying to reduce release churn so we can get some work done.
98 17:14:38 <Jason_at_Intel> I think that SideEffect is more correct in most of the cases this happens for me
99 17:14:52 <garyo> Jason: that's what I'd expect, given the testcase.
100 17:15:02 <bdbaddog> pushing the release button is all I have time for in the near future. so if I can get a handle on greg's changes I can do that.
101 17:15:10 <Jason_at_Intel> but the large products have 350 binaries in it
102 17:15:29 <Jason_at_Intel> so it hard to say that SideEffect will fix all cases developer have come up with
103 17:16:11 <Jason_at_Intel> we have some very cleaver people :-)
104 17:16:10 <garyo> If Bill's got time for a 2.0.1, I'm OK with that. Is there anything else we should squeeze in?
105 17:16:24 <Jason_at_Intel> I can wait till 2.0.1
106 17:16:29 <bdbaddog> maybe any doc changes?
107 17:16:29 <GregNoel> Sounds to me that you should try to switch to SideEffect() and if it doesn't solve your problems, reopen the question.
108 17:16:33 <Jason_at_Intel> but i hope it is in 30 or so :-)
109 17:16:42 <garyo> 30 what?
110 17:16:48 <sgk> yeah, doc changes: i still owe a writeup on SConsignFile()
111 17:16:53 <Jason_at_Intel> 30 days
112 17:17:05 <garyo> ok. Yes, I owe some doc fixes too.
113 17:17:08 <bdbaddog> I also owe some doc work as well.
114 17:17:10 <GregNoel> also
115 17:17:10 <garyo> --warn in the UG I think.
116 17:17:48 <garyo> Steven, I sent you some doc a while ago, any opinion on where that could go?
117 17:18:00 <sgk> oh, right
118 17:18:10 <sgk> i vaguely remember looking at it and not having a good idea either
119 17:18:14 <sgk> same with SConsignFile
120 17:18:30 <sgk> if it's really homeless, putting it in the Misc chapter seems as good as any
121 17:18:12 <GregNoel> (I have a question about the doc work, too, but let's return to it later; resolve this issue first.)
122 17:18:44 <garyo> I'm hearing 2.0.1 for this issue.
123 17:18:58 <sgk> so 2.0.1 with a normal checkpoint cycle, right?
124 17:19:06 <garyo> Jason needs it, it's done, and Bill has time to push it out.
125 17:19:08 <GregNoel> I'd rather see if SideEffect() solves the problem.
126 17:19:29 <garyo> He should use SideEffect where possible anyway; it's more correct.
127 17:19:39 <garyo> Ties the dependency to the proper builder.
128 17:19:34 <sgk> Jason_at_Intel: what would give your user base the most confidence?
129 17:19:44 <sgk> knowing that there's a better solution in the current code base,
130 17:19:56 <sgk> or fixing this behavior with Depends()?
131 17:19:42 <bdbaddog> GregNoel: But is SideEffect() is a workaround?
132 17:20:29 <garyo> Depends() is weird in this case anyway. It's brain-twisting that it even should work.
133 17:20:31 <GregNoel> Depends() is an accident; SideEffect() is really the right solution.
134 17:20:49 <garyo> (but I agree it should work.)
135 17:20:36 <Jason_at_Intel> I would say 2 things
136 17:21:13 <Jason_at_Intel> 1) being backwards compatible.. so teh current build does not break ( minus stuff that is really broken)
137 17:21:20 <Jason_at_Intel> 2) saying that something did not happen.. Scons is very silent on what it is doing
138 17:21:23 <Jason_at_Intel> ie
139 17:21:49 <Jason_at_Intel> it does not say .. i am ignoring this node as it has no builders... did you mean SideEffect?
140 17:21:50 <sgk> garyo: i kind of view it as Depends() should work on a file without a Builder just like it does on one with
141 17:21:57 <sgk> it's just that without a Builder, the build action is null
142 17:22:20 <sgk> but that may be because i've been brainwashed by the current implementation
143 17:22:31 <garyo> sgk: you're right, I'm kind of exaggerating. But I think everyone's right:
144 17:22:40 <Jason_at_Intel> people get unhappy when Scons when they don't get why it will not build something as they expect
145 17:22:43 <sgk> shuttle real soon....
146 17:22:40 <GregNoel> sgk, then will you fix Alias() as well? It has the same problem.
147 17:22:56 <sgk> GregNoel: good point
148 17:23:05 <sgk> since this behavior is fresh in my mind, i'll take a look now
149 17:22:55 <garyo> Depends() should be made to work as it did, and Jason should use SideEffect where it's correct to do so.
150 17:23:20 <Jason_at_Intel> it is not me... but the developer i support :-)
151 17:23:22 <sgk> biab
152 17:23:23 * sgk has quit (Quit: sgk)
153 17:23:30 <garyo> Jason: yep
154 17:23:40 <Jason_at_Intel> ya the Alias() and Depends()
155 17:23:43 <GregNoel> brb
156 17:23:44 <Jason_at_Intel> I like that to be fixed
157 17:24:02 <Jason_at_Intel> it would allow the Make virtual node idea to work as people expect
158 17:24:08 <garyo> Jason: no doubt in anyone's mind they should work.
159 17:24:54 <garyo> But do we *need* to put out an extra release, with checkpoints and bla bla bla, for it? Maybe... let me see how many 2.1 tickets we have.
160 17:25:18 <Jason_at_Intel> I know... the problem i get is I have some very passionate developer that go back and say " in my day.. this did not happen... and pigs flew"
161 17:25:35 <bdbaddog> I'm thinking since we'll be adding a lot into 2.1, that this bug fix should go without all that additional changes.
162 17:25:45 <garyo> OK, we have 68 tickets open for 2.1. This is going to take a while.
163 17:26:10 <garyo> So maybe 2.0.1 is appropriate.
164 17:27:09 <garyo> whoa, 20 of the 2.1 issues are mine :-/
165 17:27:33 <bdbaddog> Yeah. I don't want to even look at that yet..:(
166 17:27:56 <garyo> You're OK, only 5.
167 17:28:16 <GregNoel> As I said before, Depends() is an accident; SideEffect() is really the right solution. The regression should be fixed, but you should be using SideEffect().
168 17:29:12 <garyo> I think we all agree on that now. But looking at the tix for 2.1, I think 2.0.1 is OK if Bill's up for it.
169 17:29:40 <bdbaddog> yup. so we do a checkpoint? and then 2weeks later 2.0.1 right?
170 17:29:44 * Jason_at_Intel has quit (Ping timeout: 260 seconds)
171 17:29:48 <bdbaddog> this weekend is when I'll get to the build.
172 17:30:18 <garyo> Works for me; I should be able to get some doc in there too by then.
173 17:30:32 * Jason_at_Intel (~chatzilla@12.18.240.224) has joined #SCONS
174 17:30:55 * sgk (~sgk@67.218.105.226) has joined #SCONS
175 17:31:07 <sgk> am i back yet? is this thing on?
176 17:31:08 <GregNoel> It could work. It was surprisingly easy to cherry-pick individual changesets over via checkpoint. But I'd oppose bringing over anything more. (Well, maybe the doc.)
177 17:31:37 <sgk> what'd i miss?
178 17:31:58 <Jason_at_Intel> we agree that we have a lot of stuff to fix
179 17:32:02 <bdbaddog> 2.0.1 with just that fix, checkpoint build this weekend, 2.0.1 2 weeks later.
180 17:32:03 <garyo> I think we're agreeing on 2.0.1 with a checkpoint first, including only this fix and some doc
181 17:32:10 <bdbaddog> yes. + doc.
182 17:32:45 <GregNoel> done
183 17:32:22 <garyo> (and that there are 68 tickets open for 2.1, 20 of which are mine, ack)
184 17:32:27 <sgk> okay
185 17:32:48 <sgk> (the other 48 are probably mine, given my track record... :-/)
186 17:33:14 <garyo> Actually a bunch are issues@scons which I don't understand
187 17:33:43 <GregNoel> sgk, 2.1 is scheduled for October, so you've got plenty of time... {;-}
188 17:34:02 <garyo> October 2009? :-)
189 17:34:16 <garyo> j/k
190 17:34:20 <sgk> garyo: don't understand how they got that way? I returned a whole bunch that were languishing with me
191 17:34:25 <GregNoel> garyo, probably +Easy that never got assigned.
192 17:34:54 <garyo> ok, sounds plausible
193 17:35:01 <GregNoel> garyo, no, October 2010, believe it or not; it's in the roadmap.
194 17:35:26 <garyo> excellent!
195 17:35:51 * sgk scores a point for garyo
196 17:35:52 <garyo> 68 tickets in 4 months is doable I think.
197 17:36:07 <sgk> yep, sounds realistic
198 17:35:51 <GregNoel> OK, we seem to be agreed on that; resume the doc discussion?
199 17:35:57 <garyo> fine w/ me
200 17:36:58 <GregNoel> My question is where the command-line options live. I was looking for a template to start with while I was waiting for the regression tests to finish and couldn't find one.
201 17:38:13 <sgk> in the User's Guide, they kind of just show up wherever it conceptually makes sense to introduce them
202 17:38:17 * sgk goes to look for an example
203 17:38:31 <Jason_at_Intel> the is a nice section in the man page
204 17:38:52 <sgk> example: --tree= shows up in the troubleshooting section
205 17:39:26 <sgk> so it's a matter of thinking about where it makes logical sense to introduce the concept of "you can control warnings"
206 17:40:10 <GregNoel> Hmmm... I think I have --warn= and Gary has --checkdisk, but neither of them seem to have homes.
207 17:40:32 <sgk> there is a chapter that's nominally about controlling your build from the command line
208 17:40:38 <sgk> doc/user/command-line.{in,xml}
209 17:40:57 * GregNoel looks at it...
210 17:40:59 <sgk> but it's a little more about Options and stuff like that
211 17:41:14 <sgk> but maybe it provides a logical home anyway
212 17:41:25 <sgk> i could also see --warn= in the troubleshooting section
213 17:41:52 <sgk> i could see users ending up there if they ask themselves, "where do I find out how to get SCons to STFU"
214 17:42:26 <garyo> I agree -- the man page is where we put all the options together; the UG should be task-oriented.
215 17:42:47 <GregNoel> Yeah, either is a possibility; I was afraid I'd have to do an entire new page...
216 17:44:02 <GregNoel> Now that I have a clue, I'll be able to hunt down a few more examples. Thanks.
217 17:44:34 <sgk> okay
218 17:44:40 <sgk> what else?
219 17:44:44 <GregNoel> Anything else? There were some other things about doc before; are all of those answered?
220 17:45:05 <bdbaddog> .final ?
221 17:45:20 <GregNoel> What about it?
222 17:45:37 <garyo> Can we omit it, per discussion on the ml today?
223 17:45:39 <bdbaddog> Are we going to drop it and have 2.0.1 and 2.0.0,etc for the actual release?
224 17:45:44 <sgk> yeah, i was surprised to see that show up in the actual package name
225 17:45:45 * Jason_at_Intel has quit (Ping timeout: 240 seconds)
226 17:45:49 <bdbaddog> well not 2.0.0 since it's out
227 17:45:55 <sgk> right
228 17:46:45 <GregNoel> I noticed that as the release was going out, but I didn't have time to do anything about it then.
229 17:47:28 <garyo> ok, for 2.0.1 then, we're all agreed?
230 17:47:30 <GregNoel> There's a distinction between the _package_ name (*.final.*) and the _release_ name (2.0.0).
231 17:47:50 <GregNoel> We need to figure out which is used where.
232 17:48:00 <sgk> GregNoel: conceptual distinction, or just in the way I implemented the SConstruct build long long ago?
233 17:48:09 <GregNoel> Yes
234 17:48:25 <sgk> which?
235 17:48:28 <sgk> let me ask another way
236 17:48:54 <sgk> we all agree the release should ideally be named 2.0.1, not 2.0.1.final, yes?
237 17:48:59 * Jason_at_Intel_ (~chatzilla@12.18.240.224) has joined #SCONS
238 17:49:00 * Jason_at_Intel_ is now known as Jason_at_Intel
239 17:49:22 <bdbaddog> yes
240 17:49:33 <GregNoel> Yes, but when one refers to the package, it has the suffix. They're different.
241 17:49:53 <sgk> that's the next question
242 17:50:06 <GregNoel> That is, you should download 2.0.1.final.0, but it should install 2.0.1.
243 17:50:12 <sgk> GregNoel: you're saying that you think the package should be named scons-2.0.1.final.0.tar.gz ?
244 17:50:19 <GregNoel> Yes
245 17:50:34 <sgk> why? i don't know of another project that does that
246 17:50:51 <sgk> does it buy us anything other than the ordering? or is that the main motivator
247 17:50:57 <GregNoel> Because it sorts alphabetically.
248 17:51:48 <bdbaddog> Doesn't seem to be a problem for other projects, so why be diffferent?
249 17:51:48 <sgk> i personally don't find that a compelling reason to make users map between the release number and a package with a different name
250 17:52:03 <garyo> Irrespective of anything else, I think the download file of 2.0.1 should be called scons-2.0.1.tar.gz unless we have a really good reason.
251 17:52:11 <bdbaddog> concur
252 17:52:38 <garyo> Checkpoints and betas should identify themselves as such though, just as we've been doing.
253 17:52:45 <GregNoel> Well, I've missed final releases because it was buried in the list of alpha, beta, ... releases, so I have personal motivation if nothing else.
254 17:53:14 <garyo> Still, look around -- nobody else calls their finals final.
255 17:53:39 * Jason_at_Intel has quit (Ping timeout: 260 seconds)
256 17:54:17 <GregNoel> I could be persuaded, but I'd still worry about it.
257 17:54:08 <garyo> Is either way technically more difficult than the other?
258 17:54:29 <sgk> i don't think so, but i haven't looked at that code in a while
259 17:55:21 <GregNoel> garyo, yes; update-release-info has to know which values to update; it's tricky for the case of pure text files with no hints.
260 17:54:42 <sgk> GregNoel: still worry about what aspect of it?
261 17:56:14 <GregNoel> sgk, people picking the last-listed (or first-listed) simply because they missed the actual release in the middle.
262 17:56:49 <GregNoel> Look at the RPM labeling to avoid that problem.
263 17:57:24 <sgk> ?
264 17:57:26 <garyo> Yes, rpm solves that cleverly. But it's not purely alphabetical; it sorts the separate fields.
265 17:57:23 <bdbaddog> We can go non-final and see if we get any user issues..
266 17:57:34 <bdbaddog> if not we stay that way, if so we revisit.
267 17:57:41 <garyo> There's no good way if sourceforge is purely alpha.
268 17:58:26 <GregNoel> I'm certainly open to suggestions.
269 17:58:18 <garyo> I think people will figure it out.
270 17:58:51 <GregNoel> garyo, _I_ missed it, more than once. And I think I'm brighter than the average downloader.
271 17:58:55 <garyo> I think in the absence of brilliant new methods we should just do what everyone else does. Innovate in the software, not the naming.
272 17:58:59 <bdbaddog> So I'm looking at the SF ui now. newest files are at the top.
273 17:59:35 <garyo> That would be sensible...
274 17:59:38 <bdbaddog> Highlighted in green with a table tile of "newest files"
275 17:59:49 <bdbaddog> then a section labelled "all files"
276 17:59:59 <bdbaddog> I think we'll be fine with vanilla 2.0.1 labelling.
277 18:02:08 <GregNoel> OK, identify which cases need the full label and which need the short label, and I'll see what I can do with update-release-info.
278 18:02:35 <garyo> Greg's right that in some cases it will probably not sort ideally. But I think it's such a minor thing, and the ".final.0" sticks out like a sore thumb to me; for me it's mostly an aesthetic thing.
279 18:02:40 <sgk> alpha, beta, candidate all seem okay with the full label
280 18:03:30 <sgk> as a naive user, any added word (or abbreviation like "rc") is a flag to me that it's not a production release
281 18:04:28 <bdbaddog> so are we doign alpha and candidate now? or just alpha, beta, and released (where there's no additioinal text for the released version)
282 18:05:00 <GregNoel> Ah, bad timing; I'm called to dinner. I'll collect my thoughts and continue the thread on the mailing list.
283 18:05:23 <sgk> darn, i had a testing topic i wanted to talk about
284 18:05:30 <sgk> okay, i can shift that to the mailing list, too
285 18:05:40 <bdbaddog> free beers at vendor party are waiting for me...
286 18:06:04 <GregNoel> I can stall a few minutes for another topic, but this one is drawing out. Is it quick?
287 18:06:11 <sgk> probably not
288 18:06:37 <GregNoel> A quick general statement of the issue?
289 18:06:40 <sgk> trying to decide how to start converting the tests
290 18:06:55 <sgk> to the new sconstest- prefix idea
291 18:06:23 <bdbaddog> float it to release or dev mailing list?
292 18:07:15 <GregNoel> Ah. Definitely not quick. Mailing list it is. We'd need Dirk for it anyway.
293 18:07:23 <sgk> yep, good point
294 18:07:29 <sgk> we're done?
295 18:07:36 <GregNoel> I think so; g'night all.
296 18:07:40 <sgk> bdbaddog: i'll send to dev
297 18:07:41 * You have been marked as being away
298 18:08:05 <sgk> 'night
299 18:08:07 <garyo> ok folks, see you again soon. bdbaddog, have a beer for us!
300 18:08:14 <bdbaddog> will do!
301 18:08:24 * sgk (~sgk@67.218.105.226) has left #SCONS
302 18:08:55 * bdbaddog has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401064631])
303 18:09:30 * garyo (~garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has left #SCONS
304
