Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
IrcLog2009 08 25
16:41:57 * garyo-home (n=[firstname.lastname@example.org](mailto:email@example.com)) has joined #scons 16:50:31 * stevenknight (n=[firstname.lastname@example.org](mailto:email@example.com)) 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=[firstname.lastname@example.org](mailto:email@example.com)) 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
Clone this wiki locally
Press h to open a hovercard with more details.