-
-
Notifications
You must be signed in to change notification settings - Fork 320
IrcLog2009 08 25
William Deegan edited this page Jan 14, 2016
·
2 revisions
16:41:57 * garyo-home (n=[chatzill@209-6-158-38.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com](mailto:chatzill@209-6-158-38.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)) has joined #scons
16:50:31 * stevenknight (n=[stevenkn@c-67-164-61-68.hsd1.ca.comcast.net](mailto:stevenkn@c-67-164-61-68.hsd1.ca.comcast.net)) has joined #scons
16:51:41 <garyo-home> Hi Steven; how's things?
16:54:35 <stevenknight> hey gary -- too much going on, as usual, but okay
16:54:36 <stevenknight> you?
16:54:41 <garyo-home> about the same.
16:57:04 * stevenknight tries to catch up on the spreadsheet
16:58:49 * garyo-home is doing the same
17:01:11 * [GregNoel](GregNoel) is no longer marked as being away
17:01:06 <[GregNoel](GregNoel)> Looks like there are at least three of us tonight...
17:01:54 <[GregNoel](GregNoel)> As I said in my email, I can only stay a half-hour, so we should get started.
17:02:16 <garyo-home> ok, fine w/ me. I think someone is coming later too.
17:02:31 * bdbaddog (n=[bdeegan@adsl-71-131-3-224.dsl.sntc01.pacbell.net](mailto:bdeegan@adsl-71-131-3-224.dsl.sntc01.pacbell.net)) has joined #scons
17:02:33 <garyo-home> 2426 is the first...
17:02:42 <garyo-home> Hi Bill!
17:03:07 <bdbaddog> Hi
17:03:14 <garyo-home> Looking at 2426.
17:03:45 <garyo-home> I don't think tool*chain* redesign will help this issue particularly, I vote to put something reasonable in for 3.x.
17:03:51 <[GregNoel](GregNoel)> I still think it's invalid, and if we want an issue to make it configurable, we should add a new one.
17:04:24 <garyo-home> I'd be OK with that, but it'll be pretty similar to this one.
17:04:28 <[GregNoel](GregNoel)> but I'll go for 3.x with a change of subject
17:04:34 <bdbaddog> 3.x
17:04:39 <garyo-home> ok w/ me.
17:04:58 <[GregNoel](GregNoel)> done, unless Steven has something
17:05:13 <[GregNoel](GregNoel)> (He's the other "invalid" vote)
17:05:03 <stevenknight> 2426 is invalid
17:05:10 <stevenknight> he doesn't specify CPPPATH
17:05:38 <stevenknight> he'd have to add /usr/include to CPPPATH to find that <set> in preference to the current dir
17:05:56 <stevenknight> we can't know in advance what system directories a given compiler will search on its own
17:05:40 <[GregNoel](GregNoel)> Er, in that case, I'm back to invalid
17:05:42 <bdbaddog> invalid, open a new bug to make configurable
17:05:50 <garyo-home> steven: I take your meaning, but still it ought to be configurable. (Maybe Greg's right, should be a new issue.)
17:06:08 <stevenknight> configurable how? you can configure it right now in CPPPATH
17:06:30 <stevenknight> CPPPATH=['/usr/include/directory_containing_set'] would make his configuration work
17:06:33 <garyo-home> A search for a <> header should *never* match one in the current dir.
17:06:36 <bdbaddog> whether it looks in . first or last.
17:06:54 <garyo-home> (gcc and msvc don't look in . at all for <>)
17:07:29 <garyo-home> CPP_SCANNER_LOOK_IN_DOT_FOR_SYSINCLUDES
17:07:29 <stevenknight> okay, got it -- agree, new issue for configuring that behavior
17:07:45 <[GregNoel](GregNoel)> done
17:07:53 <garyo-home> ok, 2427
17:08:24 <garyo-home> Unfortunately this hack is what we have for now, I think we need to doc it.
17:08:45 <bdbaddog> doc +1
17:09:04 <stevenknight> agree, doc
17:09:04 <[GregNoel](GregNoel)> maybe doc with a note that it will disappear?
17:09:20 <garyo-home> ... when a better mechanism is implemented. Sure.
17:09:44 <garyo-home> The main thing wrong with it is it's global, and we really need a per-File thing.
17:09:57 <garyo-home> But anyway that's a different point.
17:10:12 <stevenknight> thought it was per-environment, so it can be configured
17:10:25 <garyo-home> Sorry, right it is per-env, but per-File is better.
17:10:27 <stevenknight> but I agree w/Greg's point about an Archive() being better in the long term
17:11:03 <garyo-home> I'm not 100% sure about how that would work but am willing to go with it for now.
17:11:16 <stevenknight> doc it
17:11:24 <[GregNoel](GregNoel)> is that a consensus?
17:11:27 <garyo-home> +1
17:11:27 <stevenknight> but should we mention it disappearing if we don't know what the replacement will be?
17:11:34 <stevenknight> that would bug me as a user
17:11:46 <bdbaddog> I'd say doc it, once we have a plan to replace, then add that to doc.
17:11:52 <stevenknight> +1
17:11:56 <garyo-home> Or deprecate it the usual way.
17:12:08 <garyo-home> doc it for now anyway.
17:12:20 <[GregNoel](GregNoel)> done
17:12:41 <stevenknight> 2428: consensus 3.x p4 ?
17:13:15 <garyo-home> 2428 consensus ok w/ me.
17:13:17 <bdbaddog> 2428 +1 consensus
17:13:25 <[GregNoel](GregNoel)> done
17:13:29 <[GregNoel](GregNoel)> 2429
17:14:05 <garyo-home> I think it's a real bug.
17:14:12 <bdbaddog> ditto.
17:14:17 <stevenknight> agree
17:14:47 <[GregNoel](GregNoel)> The OE is an internal object, but its effects are visible, so it's a bug.
17:14:34 <garyo-home> 2.x p2?
17:14:45 <bdbaddog> 2.x p2 +1
17:14:56 <[GregNoel](GregNoel)> agree
17:14:57 <garyo-home> agreed.
17:14:58 <stevenknight> 2.x p2
17:15:09 <[GregNoel](GregNoel)> who?
17:15:22 <stevenknight> i have a prototype of a really different substitution mechanism that looks faster
17:15:37 <[GregNoel](GregNoel)> Sounds like a volunteer to me.
17:15:37 <garyo-home> But it may not even be subst related?
17:15:53 <garyo-home> steven, go for it.
17:16:33 <[GregNoel](GregNoel)> Bug is because call is applied to Env, not OE.
17:16:40 <garyo-home> Put a note in that I'll do it if Steven doesn't get to it.
17:17:03 <[GregNoel](GregNoel)> OK, I'll add you to the issue.
17:17:14 <garyo-home> +1
17:18:00 <garyo-home> done?
17:18:20 <[GregNoel](GregNoel)> yes, done
17:18:28 <stevenknight> (sorry, afk for a bit)
17:18:56 <stevenknight> the prototype would basically replace [OverrideEnvironment](OverrideEnvironment)
17:19:15 <stevenknight> so there wouldn't be any distinction between "real" and "override"
17:19:18 <stevenknight> they're just all stackable dicts
17:19:34 <stevenknight> it takes the technique of string.Template and extends it for our purposes
17:19:43 <garyo-home> steven: that sounds great. I'll help test it :-)
17:19:49 <[GregNoel](GregNoel)> as will I
17:19:58 <stevenknight> the problem I'm running into is that subst_list() basically has really dumb and ill-defined semantics
17:20:20 <garyo-home> steven: 110% agreement there. We've been through a few oddities with it.
17:20:09 <stevenknight> i should write up a discussion for the ML
17:20:13 <[GregNoel](GregNoel)> yes
17:20:11 <stevenknight> anyway, back to the issues
17:18:13 <[GregNoel](GregNoel)> 2430, 2431, consensus
17:18:18 <garyo-home> agreed.
17:18:54 <[GregNoel](GregNoel)> 2432, 2433, consensus
17:19:18 <[GregNoel](GregNoel)> 2434, closed
17:20:31 <garyo-home> I'm fine thru 2434.
17:20:44 <[GregNoel](GregNoel)> 2441, needs priority
17:20:54 <garyo-home> p3?
17:21:01 <bdbaddog> +1 p3
17:21:05 <stevenknight> p3
17:21:06 <[GregNoel](GregNoel)> works for me
17:21:24 <garyo-home> great
17:21:39 <stevenknight> 2435: since I just attached my name to [OverrideEnvironments](OverrideEnvironments)...
17:22:26 <stevenknight> 2.x p3 stevenknight
17:22:28 <garyo-home> agreed, this one's related. It can get arbitrarily complex, but this proposal is pretty reasonable. Would it fit with stacked dicts?
17:22:46 <[GregNoel](GregNoel)> The global names are available, and I looked at how hard the implementation would be once (should also work for env.Clone()) and it didn't look that bad.
17:22:47 * stevenknight goes to look at the original issue...
17:23:43 <stevenknight> yes, i think stackable environments takes care of this
17:23:49 <stevenknight> or most of what people want from it, anyway
17:23:58 <[GregNoel](GregNoel)> This is newenv = Environment(CPPFLAGS = Append('whatever'))
17:24:22 <garyo-home> right; the override env has to append to the original env.
17:24:47 <garyo-home> anyway, Steven will look at it, let's move on.
17:25:00 <stevenknight> i don't think that specific syntax is viable, but the concept is the same
17:24:56 <[GregNoel](GregNoel)> done
17:25:18 <stevenknight> moving on...
17:25:30 <garyo-home> 2436: I'll take it
17:25:43 <stevenknight> garyo-home++
17:25:48 <bdbaddog> Gary+1
17:25:49 <[GregNoel](GregNoel)> (Hmmm... I think my spreadsheet just crashed.)
17:26:17 <garyo-home> my gdocs still shows you viewing...
17:26:28 <bdbaddog> ditto.
17:26:46 <stevenknight> 2437: consensus 2.1 p3 ludwig
17:26:57 <garyo-home> agreed
17:27:16 <stevenknight> 2438: 2.1 p3 who?
17:27:23 <stevenknight> could kick it back to Jason for the test case
17:27:31 <stevenknight> but still needs a comitter
17:27:41 <garyo-home> I'll commit it and work w/ him to get the testcase.
17:27:49 <bdbaddog> +1 gary
17:28:01 <stevenknight> thnx
17:28:54 <[GregNoel](GregNoel)> 2438, look at SQEC to see if it gives you any ideas
17:29:28 <garyo-home> 2438 wouldn't be needed w/ SQEC I agree, but in the near term...
17:31:02 <stevenknight> SQEC?
17:31:25 <garyo-home> "[SubstQuoteEscapeCache](SubstQuoteEscapeCache)"
17:31:29 <stevenknight> ah
17:28:36 <[GregNoel](GregNoel)> (Google spreadsheets lost my login, but I'm back...)
17:28:34 <stevenknight> 2439: 2.1 p3
17:28:47 <stevenknight> who?
17:29:47 <garyo-home> someone want to integrate 2439?
17:30:03 <bdbaddog> I'll take it.
17:30:10 <garyo-home> excellent
17:30:22 <[GregNoel](GregNoel)> ok, works for me
17:30:49 <[GregNoel](GregNoel)> 2440, 2442, consensus
17:30:50 <garyo-home> Greg, before you have to go, want to talk about 1.3?
17:31:06 <garyo-home> (agree w/ 2440, 2442)
17:31:45 <[GregNoel](GregNoel)> garyo-home, I'll leave my session running; I'll read it later
17:31:59 <garyo-home> ok, sounds good.
17:32:16 <[GregNoel](GregNoel)> 2443
17:32:17 <garyo-home> 2443's next.
17:32:39 <garyo-home> Steven: what about the line I list as suspect?
17:33:03 <stevenknight> 2443: sounds exactly right
17:33:25 <stevenknight> i thought sure we had/have some tests of aliases with actions
17:33:44 <stevenknight> either i'm hallucinating or those take a different code path
17:33:53 <bdbaddog> I"m looking at the path, and suspect maybe he's got a locally modified scons?
17:34:10 <bdbaddog> /home/Checkouts/Bazaar/SCons_trunk/...
17:34:05 <garyo-home> Well, this is a pretty nice testcase in the ticket.
17:34:18 <stevenknight> greg confirmed the failure
17:34:30 <bdbaddog> ah..true.
17:34:32 <bdbaddog> donno.
17:34:53 <garyo-home> There's no way that line 699 in Action.py can work.
17:34:54 <bdbaddog> is this a 1.3 type issue? or 2.x?
17:35:14 <garyo-home> Good q. What's the 1.3 schedule? Frozen?
17:35:47 * garyo-home hears nothing... great silence...
17:35:50 <bdbaddog> my understanding was. One more checkpoint wait 2 weeks if nothings seriously broken then 1.3
17:36:04 <bdbaddog> then charge forward to 2.0
17:36:19 <stevenknight> uhh....
17:36:23 <stevenknight> that line looks fine, actually,
17:36:27 <garyo-home> That works for me; if so, then this can get squeezed into 1.3.
17:36:30 <stevenknight> it's calling the Environment.subst_list() method
17:36:36 <stevenknight> not Subst.scons_subst_list()
17:36:45 <stevenknight> Environment.subst_list() does take an executor= keyword argument
17:36:47 <garyo-home> Right, but that eventually calls scons_subst_list.
17:37:11 <garyo-home> Ah, the env's subst_list should strip it out?
17:37:19 <stevenknight> right, but it doesn't try to pass executor= to it
17:37:22 <stevenknight> so far as i can see
17:37:25 <[GregNoel](GregNoel)> Taking too long; defer until next time
17:37:31 <stevenknight> [GregNoel](GregNoel)++
17:37:41 <garyo-home> hmm, ok.
17:38:03 <[GregNoel](GregNoel)> I propose to stop here and go on to 1.3 discussion.
17:38:05 <bdbaddog> put research bill?
17:38:22 <garyo-home> ok w/ me!
17:38:25 <stevenknight> 2443 research bill ok by me
17:38:38 <bdbaddog> o.k. on to 1.3
17:39:02 <garyo-home> Bill, are you still OK making the checkpoint?
17:39:05 <[GregNoel](GregNoel)> ARGV, got to go; cul
17:39:12 <garyo-home> ok bye
17:39:21 <stevenknight> later
17:39:31 <bdbaddog> Later Greg!
17:39:37 <garyo-home> I've done one before, I can help if needed.
17:39:49 <stevenknight> if it would help, i could open up the system that I use for cutting the releases
17:39:53 <bdbaddog> yes. Just taking a bit to get the changes together and coherent. the other parst are easy.
17:39:55 <stevenknight> it's a VM
17:40:04 <bdbaddog> ahh.
17:40:10 <bdbaddog> how big's the footprint?
17:40:24 <bdbaddog> I can bring you a usb hardrive..
17:40:33 <stevenknight> i was going to let you ssh in
17:40:38 <bdbaddog> oh. o.k.
17:40:53 <stevenknight> but the creation of the image is also automated
17:41:22 <garyo-home> I have a small VM (ubuntu) that can build a release, w/ doc tools etc. if that helps?
17:41:47 <bdbaddog> I'm not too worried about that part. It's just been tough getting a block of time to get the text part together.
17:42:09 <stevenknight> that's usually been the most time-consuming part for me, too
17:42:29 <bdbaddog> I think we should start to enforce/encourage update Changes.txt with each checkin.
17:42:37 <bdbaddog> and the release message.
17:42:50 <bdbaddog> though svn would be fine too.
17:43:01 <bdbaddog> and then pushing the button is easy.
17:42:35 <garyo-home> Want to write it as a google doc w/ irc?
17:42:45 <garyo-home> +1 on both of those!
17:43:22 <bdbaddog> I'll try and get it done tonight.
17:43:39 <garyo-home> OK, if you want review just let me know.
17:44:15 <stevenknight> agree on CHANGES.txt
17:44:19 <bdbaddog> sure. I'll send out text to release mail list for review. And then how do we post it to all the correct places.
17:44:32 <garyo-home> That, for me, was time consuming.
17:44:45 <stevenknight> yes
17:44:46 <bdbaddog> Changes.txt and release notice.
17:44:50 <garyo-home> Tigris, sf, website...
17:45:15 <stevenknight> first, we should give you appropriate privileges on those sites
17:45:24 <stevenknight> and then second, there's gotta be a way to automate doing those
17:45:13 <bdbaddog> so the changes and release are since 1.2.x or since last checkpoint?
17:45:36 <stevenknight> last checkpoint
17:45:53 <garyo-home> (but the 1.3 changes will be from 1.2)
17:45:59 <bdbaddog> yes.
17:45:57 <stevenknight> originally i started trying to adjust CHANGES.txt so it would be since last release (e.g. 1.2.x)
17:46:01 <stevenknight> but that got too confusing
17:46:25 <stevenknight> seemed easier to grok that all of the accumulated checkpoints since the last 1.2.x line in CHANGES.txt
17:46:31 <stevenknight> were part of 1.3.x
17:46:26 <garyo-home> If we have people update it on commit, won't it have to be since last release?
17:46:30 <bdbaddog> Could have Changes.release.txt and Changes.Checkpoint.txt or something like that.
17:47:02 <stevenknight> ? not following
17:47:17 <garyo-home> Maybe on release we could just remove the checkpoint lines, leaving only the changes?
17:47:21 <bdbaddog> so 3 files. Changes.txt which is running change list.
17:47:44 <bdbaddog> hmm. never mind..
17:47:50 <bdbaddog> o.k. I like Gary's idea.
17:48:02 <stevenknight> could do that
17:48:02 <bdbaddog> since the checkpoints are discardable.
17:48:14 <garyo-home> right.
17:48:24 <stevenknight> but I think some people do treat the checkpoints as releases
17:48:45 <stevenknight> is there actual harm in preserving the info?
17:48:53 <garyo-home> it's just visual noise.
17:49:08 <garyo-home> Maybe we indent those or something.
17:49:19 <bdbaddog> O.k. also, let's checkin the announcment file, which get's wiped clean at each real release?
17:49:45 <bdbaddog> And for checkpoints, let just refer people to the changes.txt ?
17:50:16 <garyo-home> +1 on checking in the announcement file for sure.
17:50:33 <stevenknight> dunno, doesn't seem worth extra effort to remove and reorganize
17:50:42 <stevenknight> +1 to checking in announcement
17:50:49 <stevenknight> yeah
17:51:17 <bdbaddog> O.k. I"ll check in a Blank.
17:51:30 <garyo-home> release-announcement.txt? RELEASE.txt?
17:51:53 <bdbaddog> Announcement.txt ?
17:52:08 <garyo-home> works for me
17:52:46 <stevenknight> announcement.txt (your choice capitlization)
17:53:11 <garyo-home> So for changes.txt we'll leave the checkpoints in for now (maybe indent or something)?
17:53:46 <bdbaddog> Yes. I guess we can just leave what's there now. And when we go 2.0 move Changes.txt to Changes-1.txt
17:53:53 <bdbaddog> In 2.0 indent checkpoints?
17:54:31 <garyo-home> Sure, we can iron out the details when we get there.
17:54:49 <stevenknight> yeah
17:54:51 <garyo-home> (I'd be OK w/ deleting the older checkpoints too, just keep 1 release back or so)
17:55:23 <bdbaddog> Can we breach a 2.0 topic?
17:55:24 <bdbaddog> ;)
17:55:27 <stevenknight> but i personally wouldn't invest a lot of time on it, it doesn't seem like anyone's really complaining
17:55:38 <bdbaddog> ok.
17:55:42 <garyo-home> agreed.
17:55:50 <garyo-home> sure, 2.0?
17:55:56 <stevenknight> to really clean it up, you not only have to delete the checkpoint lines, but you have to merge the individual contributor sections
17:56:06 <garyo-home> (good point)
17:56:00 <stevenknight> 2.0
17:56:30 <bdbaddog> :) My normal python question. Since time has marched on and we drew the line in the sand a while back, can we more to a newer version for 2.0 than python 2.2?
17:57:25 <garyo-home> what features would we gain by going to, say, 2.3?
17:57:51 * stevenknight will go with the collective wisdom
17:57:53 <bdbaddog> 2.5 gets us subprocess right?
17:57:53 <stevenknight> that said
17:58:23 <stevenknight> 2.3 did seem only marginally better than 2.2
17:58:27 <stevenknight> 2.4 starts to get significant
17:58:29 <stevenknight> iirc
17:58:51 <garyo-home> We already have a bunch of compat stuff; I think it would have to be a language feature.
17:58:53 <stevenknight> i don't think modules (e.g. subprocess) are a compelling reason to prefer one over the other
17:58:59 <stevenknight> because we can handle them in compat
17:59:18 <stevenknight> agree w/gary, language features are stronger determinants
17:59:33 <bdbaddog> 2.5 gets' with.
17:59:41 <garyo-home> What about unicode? Anything important?
18:00:08 <stevenknight> i'd have a hard time going with 2.5; google internal standard is still 2.4
18:00:20 <garyo-home> Bill: do you think we could really jump all the way to 2.5 though? We'll lose all the IRIX people for sure, and some older Linuxes too.
18:00:47 <bdbaddog> does python 2.5 not build on irix?
18:01:02 <bdbaddog> 2.4 gets us generators.
18:01:15 <garyo-home> Last I knew the latest nekochan build was 2.3.
18:01:26 <bdbaddog> do you not build from sources?
18:02:11 <garyo-home> I take it back, there's a 2.5.2 there now.
18:02:38 <garyo-home> (It's not what *I* do, it's what my *users* do. :-/)
18:02:50 <bdbaddog> ahh. users=customers?
18:02:54 <garyo-home> yep.
18:02:59 <bdbaddog> they build from sources?
18:03:04 <stevenknight> 2.3 gets generators
18:03:15 <garyo-home> of course they won't run scons. I'm just using them as an example of "typical IRIX users"
18:03:32 <garyo-home> generators are very useful.
18:04:00 <stevenknight> 2.4 has decorators, which are kind of nifty but basically syntactic sugar for something you can code by hand
18:04:03 <garyo-home> ... but you can import generators from future in 2.2 (I think)
18:04:12 <bdbaddog> I've never been in an environment where I couldn't build a new version of scripting language for use by build system.
18:04:38 <bdbaddog> true on decorators, but anything which makes the code easier to read will be a win..
18:04:48 <stevenknight> true
18:04:56 <garyo-home> One good thing is, once we have Lukas's all-in-one Windows installer, we won't even require python on a windows box.
18:04:59 <bdbaddog> I'd be up for saying 2.5, pushing the checkpoitn with it and 1.3
18:05:06 <bdbaddog> and if the world freaks out, we backtrack.
18:05:14 <bdbaddog> we'lll have some time before 2.0's out.
18:05:27 <stevenknight> probably
18:05:50 <stevenknight> i'd have a lot of internal projects thought that would break
18:06:13 <stevenknight> though
18:06:16 <garyo-home> I'd be pretty scared to go to 2.5
18:06:32 <stevenknight> i can see either 2.3 or 2.4
18:06:34 <bdbaddog> steven - due to 2.4 internal to google?
18:06:41 <stevenknight> yes
18:06:41 <bdbaddog> o.k. let's go with 2.4
18:07:01 <bdbaddog> If we slip another 6 months or more on 2.0, then revisit.
18:07:07 <bdbaddog> and/or google updates to 2.5..
18:07:09 <bdbaddog> ;)
18:07:13 <stevenknight> yes :-)
18:07:27 <bdbaddog> Gary - what'd be the basis of your fear?
18:07:40 <garyo-home> from [http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html](http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html), 2.4 was Nov 2004.
18:07:43 <bdbaddog> then again I"m the let's break some egg's kind of guy.
18:07:55 <bdbaddog> 5 years ago almost.
18:07:55 <stevenknight> how about we poll the ML for objections to 2.4, with 2.3 as the fallback?
18:07:57 <garyo-home> My fear? We lose users due to them not being able to upgrade their pythons.
18:08:10 <garyo-home> +1 on poll ML (again :-))
18:08:12 <bdbaddog> they'll yell at us, and we can backtrack.
18:08:39 <bdbaddog> I think the mailing list hasn't provided any insight, and the only reall proof will be when the tool starts yelling at the users.
18:08:42 <stevenknight> okay, how about: release 1.3 first
18:08:48 <bdbaddog> :)
18:08:49 <stevenknight> then float 2.4 on the ML
18:09:06 <bdbaddog> well we'd be putting the warning in 1.3 about next version 2.x minimum right?
18:09:31 <bdbaddog> that's why I bring it up now.
18:09:54 <garyo-home> hmm.
18:10:13 <stevenknight> ah
18:10:45 <garyo-home> even if disablable, that's a little annoying.
18:10:59 <bdbaddog> don't we alreayd have that in place for 2.2?
18:11:11 <garyo-home> do we?
18:11:25 <stevenknight> sorry bill, you kicked the ball in your own goal -- i'm back to preferring 2.3 ... :-)
18:11:41 <bdbaddog> oh dude.. ur killin me.
18:12:06 <bdbaddog> 2.3 is 2003.
18:12:08 <garyo-home> (my vm is being annoying, or I'd look)
18:12:11 <bdbaddog> 6 years aog.
18:12:20 <stevenknight> so we turn the clock forward five years!
18:12:27 <bdbaddog> wheel's were square then.
18:12:37 <stevenknight> that's almost half way!
18:12:40 <stevenknight> :-)
18:12:58 <garyo-home> Steven: what changed your mind 2.4 -> 2.3? I don't think we'd lose that many users.
18:13:01 <bdbaddog> I don't think anyones using 2.3
18:13:08 <stevenknight> having to put the warning in 1.3
18:13:23 <garyo-home> But Bill's saying we already have a warning.
18:13:27 <bdbaddog> we can always patch it back in 1.3.1 if we get a lot of negative feedback.
18:13:52 * stevenknight breathes deeply
18:14:01 <stevenknight> oooo... kayyyy....
18:14:14 <bdbaddog> it'd be a 1 line patch and realease. if it's really bad.
18:14:36 <stevenknight> you want to make the change in this checkpoint? or only for 1.3 release?
18:15:04 <bdbaddog> hmm.
18:15:08 <garyo-home> If we get zero feedback from the warning, then I think we're safe. If we get even one negative, I'll want to revisit.
18:15:12 <bdbaddog> if the codes already there then for checkpoint.
18:15:21 <garyo-home> bdbaddog: agreed.
18:15:22 <stevenknight> warning in a checkpoint, or in a release?
18:15:40 <garyo-home> both (assuming it's already there now)
18:15:40 <bdbaddog> checkpoint if the check is already there, otherwise 1.3
18:15:59 <stevenknight> although some people treat checkpoints as release, people that are still using 2.3 are unlikely to track checkpoints
18:16:23 <stevenknight> so silence from the checkpoint warning has strong potential to be a false positive
18:16:25 <garyo-home> agreed. iit needs to be there in 1.3 anyway.
18:16:50 <stevenknight> okay, i can go with it
18:17:04 <stevenknight> now we just have to twist Greg's arm after he reads this... :-)
18:17:08 <bdbaddog> codes already there.
18:17:12 <bdbaddog> :)
18:17:22 <bdbaddog> eh.. sorry I can't hear you.. zztt zttt static on the line..
18:17:26 <bdbaddog> True.
18:17:27 <garyo-home> ... so our existing checkpoint is already warning at 2.2?
18:17:29 <stevenknight> you sneak, you... :-)
18:17:34 <bdbaddog> yes. already there.
18:17:42 <bdbaddog> I didn't do it. somebody else did it.
18:17:52 <stevenknight> oh, wait -- i knew it was warning re: 2.2
18:17:57 <garyo-home> Right, I kind of remember that now.
18:18:00 <stevenknight> i thought you meant you already checked in the 2.4 warning
18:18:00 <bdbaddog> yes warning 2.2
18:18:11 <bdbaddog> no.. didn't do that.. dang. wish I'd thought of that.
18:18:13 <garyo-home> So we just bump that warning level up a notch.
18:18:20 <bdbaddog> exactly.
18:18:21 <stevenknight> right
18:18:23 <garyo-home> or two.
18:18:29 <stevenknight> or .2
18:18:30 <bdbaddog> +.2
18:18:36 <garyo-home> ok, I'm on board, let's see what happens.
18:18:49 <bdbaddog> o.k. I just don't want the project to get stuck in the past like Plone..
18:18:58 <bdbaddog> and be too worried about moving forward.
18:19:18 <garyo-home> right, or like not changing Makefile tab syntax because it already had 100 users.
18:19:45 <garyo-home> ok, so we can call it a night I think?
18:19:52 <bdbaddog> yes. Thanks to all!
18:19:55 <garyo-home> Bill, let me know if I can help w/ the checkpoint.
18:20:10 <bdbaddog> will do. I'll try to get the text out tonight and packages ready too.
18:20:17 <garyo-home> Sounds great.
18:20:34 <garyo-home> Thanks all.
18:20:36 <garyo-home> cul
18:20:40 <bdbaddog> if whomever can give me access to the appropriate uploads I'd need can do that and/or push the packages when done.
18:20:59 <garyo-home> Oh yeah, Steven, can you do that?
18:21:40 <garyo-home> I'll email you the website login/password, Bill.
18:22:03 <bdbaddog> k. thanks.
18:22:11 <stevenknight> okay, i'll add bill to SF, tigris.org and... what else?
18:22:21 <stevenknight> feel like i'm missing something
18:22:26 <stevenknight> pair.com?
18:22:37 <garyo-home> I think it's just those two, I'll get him the pair login/password.
18:22:46 <stevenknight> okay, i'll take sf and tigris.org
18:22:48 <stevenknight> many thanks guys
18:22:52 <garyo-home> np
18:23:08 <garyo-home> 'night.
18:23:16 <bdbaddog> night!
18:38:17 * garyo-home has quit ("[ChatZilla](ChatZilla) 0.9.85 [Firefox 3.5.2/20090729225027]")
19:12:38 * stevenknight has quit (Read error: 110 (Connection timed out))
20:31:57 * [GregNoel](GregNoel) has been marked as being away