IrcLog2008 09 01

14:02:46 * bdbaddog (n=[email protected]) has joined #scons 17:52:09 * garyo-home (n=[email protected]) has joined #scons 18:34:05 * stevenknight (n=stevenkn@nat/google/x-9260060d231f4d90) has joined #scons 18:51:25 Hi, Steven. 18:52:01 * GregNoel is no longer marked as being away 18:58:29 hey gary 19:00:47 Just you & me so far... 19:01:19 <GregNoel> No, I'm here 19:01:30 Ah, hi Greg! 19:01:32 <GregNoel> just getting a soda 19:01:50 hey 19:02:18 <GregNoel> Anybody else here for the bug party? 19:02:11 Hope everybody's had a good holiday. 19:02:39 <GregNoel> More than a holiday for us; three birthdays to celebrate... 19:02:45 ? 19:02:48 Wow! 19:02:50 wow 19:03:05 <GregNoel> not to mention baby-sitting 19:03:01 kids or grownups? 19:03:41 <GregNoel> the birthdays are grownups, well, sorta, our niece is a "kid" despite the fact that she has two kids of her own 19:04:05 Sounds like a big party. 19:04:26 <GregNoel> multiple rounds of parties; I've been stuffed this weekend 19:04:44 <GregNoel> and I can't wait for Tuesday so I can get some rest... 19:04:49 :-) 19:04:42 I took my son sailing for the first time (he's 9). First time with him actually crewing at least. 19:05:01 <GregNoel> You sail? 19:05:09 Just a little -- small boats. 19:05:24 very cool 19:05:27 Would like to do more, but have neither time nor money. 19:05:28 i love those growing-up milestones 19:05:32 <GregNoel> I used to sail Sabots and others of that class, but it's been a while 19:05:42 Carl (my son) was pretty excited. 19:05:53 <GregNoel> It's a lot of fun... 19:06:36 We sail at MIT, a boat called a Tech Dinghy. 12.5', cat rigged. A little bigger than a Sabot maybe? 19:07:24 <GregNoel> Yes, a Sabot is about two meters 19:07:08 <GregNoel> Polly (wife) and I rented a boat in the Bay of Islands (New Zealand) a few years ago and sailed for a day, 32', biggest boat I've ever sailed by myself 19:07:41 I bet that was a wonderful time. I'd love to sail something like that down the east coast of the US. 19:07:53 <GregNoel> Maybe someday.... 19:08:03 Saving for retirement... 19:08:20 <GregNoel> Retirements turn out to be for the great-nephews.... 19:08:32 Hmm, yes I can see how that could work. 19:08:20 OK, shall we get started? 19:08:23 <GregNoel> yes 19:08:53 So we're starting with the current issues, right? 131 first? 19:08:58 Sorry I mean 2131 19:09:21 <GregNoel> yes. I'll go along with sorting it; Steven makes a good point. 19:09:17 I'm happy to do it since I want it to sort. 19:09:32 <GregNoel> works for me 19:09:45 okay, 2131 1.1 19:09:55 <GregNoel> pri? 19:10:05 p2 or p3 ? 19:10:12 p2 ok? 19:10:23 <GregNoel> It ought to be simple; p2 to get it done 19:10:33 2131 1.1 p2 19:10:33 done 19:10:33 agreed 19:10:38 <GregNoel> done 19:10:56 1307: consensus patch, 1.1, Ludwig 19:11:05 <GregNoel> 1307 consensus 19:10:59 p...3? 19:11:13 <GregNoel> Hmmm... p2 19:11:28 okay p2 19:11:34 done 19:11:46 <GregNoel> I was hoping he'd try to sneak it in 1.0.1 so we could say it was something we missed... 19:11:47 I don't care p2 or p3... I'll say p3 to let other things bubble up more. 19:12:19 <GregNoel> either works, he has relatively little to do 19:12:36 1.0.1 has left the station as far as i'm concerned 19:12:56 <GregNoel> well, the comment was for last week, which didn't happen... 19:12:59 (i'm getting into this move-the-release-along mindset... :-)) 19:13:10 <GregNoel> that's a good thing! 19:13:25 exactly 19:13:29 so... on to 1973: 19:13:59 <GregNoel> Gary, the src_dir in your comment is redundant. 19:14:02 Greg, I see your point about the semantics being not well thought out 19:14:16 but there's a legitimate use case that it does solve 19:14:23 Greg: thought it might be. But the doc disagrees if I remember rightly (says it'll use the parent's dir) 19:14:39 <GregNoel> I was wrong when I wrote it, hadn't checked; the new manpage patch fixes that 19:15:20 Steven: agree we shouldn't remove the functionality. In the med-long term, should fix it if possible. 19:15:24 <GregNoel> stevenknight, what use case? 19:15:35 <GregNoel> I couldn't find one. 19:15:54 you can't put a SConscript file in a directory because you don't own it 19:16:03 e.g. it's pulled from a repository into which you can't drop files 19:16:11 but you still need to build that module for inclusion in your software 19:16:30 the idea is that you should be able to set src_dir to point to that directory 19:16:31 Oho, that is very interesting! I have a couple of those myself! 19:16:43 and the build happens as if the SConscript file lived in the src_dir 19:16:44 <GregNoel> Use a parallel tree in front of the repository; I do that all the time 19:17:05 Greg: example? 19:18:20 <GregNoel> Uh, too long to show here, but not hard. Create a parallel tree and use Repository twice, once to point to the overrides and once to point to the actual files 19:19:11 I see. May have to try that idea out. I'm tired of putting SConscripts in 3rd party code I use. 19:19:12 <GregNoel> stevenknight, I'm thinking about your case, and I'm not sure it works as you expect 19:19:35 agreed, it probably doesn't in all cases 19:19:45 <GregNoel> garyo-home, yes, that's how I SConfiscate third-party stuff I want to use 19:19:46 it does for the use cases in the tests of src_dir, though 19:20:06 Greg: if src_dir worked as steven suggested, it would be pretty nice though. But that's another ticket. 19:20:12 <GregNoel> I'll have to try xxxx ah, doorbell, hang on 19:20:24 i also agree that generalizing this by using a flavor of Repository would probably end up much simpler 19:20:48 garyo: any chance you could let Google fly you out here for the GSoC mentor summit? 19:20:53 i know you're really busy... 19:21:01 So the current ticket: (a) do nothing, (b) doc changes per Greg's work, or (c) try to make it better now? 19:21:17 1973: i say do nothing for now 19:21:32 let src_dir die when VariantDir() dies 19:21:42 What I'd really like is for Greg to write up what he tried and what does and doesn't work (with tests) 19:21:49 yes 19:22:45 At least that could go in the wiki or better yet in the bug list and when people whine on the mailing list we could point them there. 19:24:20 <GregNoel> I'm back; give me a chance to catch up 19:24:27 okay 19:25:47 Steven: I missed you offer of coming to the mentor summit. I'd love to, but way too much going on unless I can combine it with a work meeting. When is it? 19:26:11 eh, now i have to go check... :-) 19:26:17 <GregNoel> I think my test cases died in our power failure, but I can try to recreate them 19:26:49 <GregNoel> The summit is 25 October for the weekend 19:27:05 Greg: too bad! I think it's worth it, unless src_dir is just going to die anyway (in favor of Repository or whatever) 19:27:13 <GregNoel> We're planning to drive up, wrap a little holiday around it 19:27:35 Steven: 25 Oct, I'll check and see. May not know for a little while yet. I'll go back & read all those msgs I deleted :-) 19:28:10 no problem 19:28:32 <GregNoel> Assuming we're invited, of course... 19:28:30 greg, you okay with letting src_dir be until we can replace VariantDir() with a generalized Repository interface? 19:29:22 <GregNoel> Works for me; after you spent all that time convincing me they were different, I'd like to see what you come up with 19:29:44 :-) 19:30:10 fair point 19:30:13 <GregNoel> For one thing, VariantDir creates new filesystem space, Repository doesn't 19:30:42 OK, so how about we save 1973 for discussion of what src_dir should/could be, but defer it. 19:31:22 <GregNoel> Let's just leave it with Steven as an 'anytime' and wait for either a wiki page or a mailing list discussion 19:31:32 okay 19:31:35 don't hold your breath... :-) 19:31:39 2087: 19:32:03 consensus 1.x p3 ludwig, right? 19:32:03 consensus 1.x p3 ludwig 19:32:03 <GregNoel> consensus 19:32:04 yes 19:32:04 <GregNoel> yes 19:32:16 <GregNoel> done 19:32:24 2183: i'm okay with 1.0.x 19:32:26 <GregNoel> 2183 19:32:44 2183: didn't read carefully enough to make sure this wouldn't have unintended consequences. Either of you? 19:33:06 (But it looks fine in the quick read I gave it.) 19:33:39 <GregNoel> All it does is add a suffix. I don't know what .sx is, but it appears harmless otherwise. 19:34:06 ok then. 19:34:13 <GregNoel> who? 19:34:35 not me! 19:34:35 I'll do it. 19:34:35 <GregNoel> Not seeing any volunteers, I'll do it 19:34:49 <GregNoel> Ah, a little overlap 19:35:16 <GregNoel> Gary, I may have more spare time over the next couple of weeks 19:35:35 OK, it's yours then. That's not a sentence I would be likely to utter. :-/ 19:36:02 <GregNoel> {;-} 19:36:03 How about 2184, a little more interesting? 19:36:27 :-) 19:37:12 I'm w/ Steven on 2184. 1.1, p3, accept patch as is. I'll do it. 19:38:03 <GregNoel> OK, I guess I missed the issue. SCons should normally duplicate LIBPATH entries when using VariantDir or Repository 19:38:21 <GregNoel> It'd be a bug if it didn't 19:38:46 You have a point. But this bug is not about that exactly. 19:39:16 <GregNoel> OK, I'll let you untangle it 19:39:22 Will do. 19:39:31 <GregNoel> 1.1 p3? 19:39:44 OK. 19:39:45 done 19:39:45 <GregNoel> done 19:39:59 2185: bill's not here to defend himself... :-) 19:40:25 Greg: I think we agree. You say wontfix, I say doc, but nobody wants the new function. 19:40:37 <GregNoel> Concur 19:40:47 I'll try to write up something for 1.x. P4 ok? 19:40:52 <GregNoel> works 19:41:31 <GregNoel> (Bill had the original issue about Explicit, changed to a doc issue, so this really shouldn't be necessary) 19:42:06 <GregNoel> 2166 consensus? 19:42:10 2166: yep 19:42:17 yes 19:42:20 2186: 19:42:34 I looked at this, I think it's OK as is. 19:42:46 makes sense to me 19:42:50 OP should just use F90PATH. 19:43:03 <GregNoel> I hadn't found F90PATH, but that makes sense 19:43:12 <GregNoel> wontfix 19:43:32 It's in the man page, I just checked. 19:44:46 <GregNoel> hello? 19:44:49 So 2187? 19:45:19 <GregNoel> 2167 consensus? 19:45:33 ? 19:45:42 2167 or 2187? 19:45:44 what number are we on? i thought 2186 wontfix 19:45:47 <GregNoel> oops, 2187 consensus? 19:45:47 2187: 19:46:53 <GregNoel> teeny, tiny little numbers, can't read them... 19:45:59 yes, 1.0.1 greg 19:46:00 2186: consensus wontfix 19:46:07 er... 19:46:39 and 2187: consensus 1.0.1 greg (?) 19:46:51 yeah 19:47:04 2187: 1.0.1 greg 19:47:09 <GregNoel> done 19:47:14 greg, you can get that in tonight/tomorrow? 19:47:31 i'm going to try to turn the checkpoint into 1.0.1 tomorrow (other time commitments allowing) 19:48:00 <GregNoel> 2187? 19:48:19 right 19:48:24 the FindFile man page fix? 19:48:31 <GregNoel> Hmmm... I should be able to, but no promises... 19:48:41 okay, i won't hold up things 19:48:59 given the chaos i might not make my target anyway... :-/ 19:49:25 <GregNoel> what, a slip already??? 19:50:04 <GregNoel> 2188, consensus 19:50:21 2188: consensus 1.x p4 greg? (yes, interesting case!) 19:50:22 <GregNoel> 2189, consensus 19:50:47 agreed 19:50:51 yes, 2189 too. 19:51:16 agreed 19:51:18 2190: 19:51:30 not sure here 19:51:48 Steven: you want to make porting autoconf scripts easier, right? 19:52:01 Even if it's basically redundant functionality? 19:52:25 <GregNoel> I concur with the point, but I don't think this is the issue 19:52:51 Greg: what's the real issue for you? 19:53:09 <GregNoel> Replacing Configure contexts with something better 19:53:08 yeah, it feels like it's more inconsistency the user has to track if they're mentally in autoconf-land 19:53:22 and have to do some of the tests completely differently because SCons has Python available 19:53:25 steven: I think I agree, having thought about it. 19:54:13 Greg: point taken, but not a great answer for this ticket. And anyway, wouldn't we still need an autoconf-syntax-like CheckFile()? 19:54:36 i think you want one, no matter what the solution ends up looking like 19:54:58 I now think it should be 1.x p4, implemented as Greg suggests. 19:55:01 <GregNoel> Maybe. What does it buy is to support two mechanisms? One that works only in a Configure context and one that works everywhere? 19:55:34 configuration checks look consistent 19:55:39 Greg: as Steven says, if the user is porting their autoconf script, they're looking in our Configure doc to discover the mappings. 19:55:49 <GregNoel> Hmmm... 19:55:57 less having to look in the manual for, "wait, how do I do this check vs. that check?" 19:56:19 <GregNoel> OK, I guess. 19:57:20 OK then. 1.x p4(?) but who? Can we assign someone else? Needs test, doc, etc. - more work than implementation. 19:57:58 <GregNoel> (There are actually dozens of tests we could implement, and should eventually, but I'd rather apply that effort to creating a better-integrated Configure replacement.) 19:58:07 i do agree with that 19:58:27 i forget, this one doesn't come with a patch, does it? 19:58:57 <GregNoel> I don't think so; he's a newbie 19:58:55 no 19:59:02 1.x p4 19:59:09 <GregNoel> done 19:59:10 invite him to submit a patch, ask on the dev list for help, etc. 19:59:17 <GregNoel> wilco 19:59:29 Greg: I agree, but this seems pretty small. OTOH, lots of small things == same effort as redo. I like what Steven just suggested while I was typing. 19:59:59 yeah, not big enough to distract from other important things 20:00:06 but might be perfect to get a newbie more involved 20:00:11 <GregNoel> OK, that closes this spreadsheet. On to the discussion? 20:00:15 OK, that's the whole new issue sheet. 20:00:26 yeah 20:00:28 Yes, 1.0.2 vs. 1.1, right? 20:00:31 here's my thinking 20:00:42 doesn't seem like we have any burning fires that would require a 1.0.2 20:00:50 <GregNoel> yes 20:00:50 agreed 20:01:04 so the next release is 1.1 in three, maybe four weeks 20:01:10 with whatever we can fit 20:01:14 <GregNoel> too short 20:01:34 it's too short only if you're trying to fit a specific set of features into it 20:01:34 <GregNoel> I'd like to shoot for a 1 Nov release of 1.1 20:01:47 3/4 wks too short for all the issues marked 1.x, but we could subset them? 20:01:55 <GregNoel> so a RC checkpoint a week ahead of that 20:01:58 right 20:02:09 3 weeks RC checkpoint, 4 weeks 1.1 20:02:15 with whatever fits w/in 3 weeks 20:02:26 <GregNoel> There are about 20 issues in 1.0.1 and 1.0.x 20:02:39 <GregNoel> no way we could do them in a month 20:03:07 <GregNoel> including the ones already slated for 1.1, plus a few from 1.x p1 20:04:05 so if we don't do them all in a month, what's the real harm? 20:05:02 <GregNoel> oops, that's 30 issues, I typoed 20:05:17 (I hate tigris's bug tracker formatting, can never find what I want.) 20:05:48 <GregNoel> You can can bookmark queries 20:06:27 Yes, I need a good set of those. Wish I could title them too. But anyway... 20:05:38 <GregNoel> I thought you could change the title in Firefox? 20:06:51 <GregNoel> To me, a month is more like a bug-fix release; a typical release is three months. Two months is a quick cycle for a "normal" release 20:07:09 okay 20:07:19 <GregNoel> (Actually I put the queries on my home page in my wiki...) 20:07:48 good idea! 20:07:59 but is there any real harm in shipping what we have in three weeks and saying that's 1.1? I don't see it 20:08:34 Steven: do you have some issues that need to be fixed soon for your customers? 20:08:34 <GregNoel> If you release too often, people stop upgrading 20:08:53 Good evening all, just read the whole meeting thus far. With Regard to 1.0.x vs 1.1 vs 2.0 20:09:05 I just think not much will have changed significantly in 3 weeks (but I'll do my best) 20:09:11 <GregNoel> it's too much hassle to keep upgrading every month 20:09:25 what I've seend is 1.0.x is bugfixes. 1.1 would be feature addition, 2.x would break some compatability. 20:09:28 no one's forcing anyone to upgrade every month 20:09:28 <GregNoel> Hi, Bill 20:09:31 Hi Bill! 20:09:37 Hi. 20:09:40 just because you "release early, release often" 20:09:46 So I may actually agree with Greg on this one.. 20:09:49 :) 20:10:03 shock! horror! drama! 20:10:06 <GregNoel> but the one-decimal releases are intended to be places where people upgrade 20:10:07 unless theres a significant feature, 1.1 may not make sense. 20:10:19 So call it 1.0.2 then? 20:10:42 well, i guess the question is whether we're going to be feature-driven or date-driven, then... 20:10:44 I think so, unless there's a bug fix scheduled which is a notable feature. 20:10:48 <GregNoel> "release early, release often" applies to development releases 20:11:11 You can go date driven releases, but number as I mentioned. 20:11:39 I think date driven makes real sense, although you may end up needing feature or 1.1 devel branch then. 20:11:46 okay, so... how about this... 20:11:52 next release is in three weeks 20:12:06 but we don't decide on whether it's 1.0.2 or 1.1 until the checkpoint date comes 20:12:18 depending on what gets fixed/added ? 20:12:19 and we decide based on what's actually in there? 20:12:22 <GregNoel> hmmm... 20:12:22 Right, depending on contents. 20:12:22 yes 20:12:28 sounds good to me. 20:12:36 I can go with that. 20:12:36 <GregNoel> problem is, one doesn't know what to focus on 20:12:47 that way we can stay consistant with what version number changes mean. 20:12:51 Highest priority? 20:12:52 that's what we're doing here, isn't it? 20:13:21 <GregNoel> yes, but highest priority has a number of new features 20:13:52 I have to go, guys -- I'll read your decision later. 20:13:57 Greg: I see what you're saying, but in some sense we'll end up with many equivalent priority bugs, so at some point it will come down to interest level in the bug and ability to reproduce environment/toolset. 20:14:07 Gary - Good night to you! 20:14:08 sure, so we're now saying highest priority of the union of 1.0.x and 1.x issues are all candidates for this next release 20:14:10 <GregNoel> three weeks implies 1.0.2 but new features implies 1.1 20:14:13 g'night. 20:14:17 <GregNoel> G'night 20:14:26 if three weeks implies 1.0.2 what does imply 1.1? 20:14:40 <GregNoel> two or three months 20:14:45 Greg: Three weeks doesn't imply 1.0.2 nor 1.1, just a time frame for next release. 20:14:51 with no intervening release? 20:15:12 i don't agree with the idea that the only way to release a 1.1 is to go dormant for 2-3 months 20:15:14 This is fairly common in commercial products in my space. Someone fixes/add's something notable you bump the minor version at the next release interval. 20:15:38 No real issue (for the most part) with customers accepting it. 20:15:40 <GregNoel> But how frequent are the releases? 20:15:51 monthly sounds like to me? 20:15:53 ~ monthly 20:15:54 yes 20:16:52 <GregNoel> bdbaddog, I meant how often are the commercial releases. Not every month, I'm sure 20:16:56 Greg: can you explain why you see 1.1 tied to a specific timeframe vs 1.0.2? So we can understand, I think that's the gap we're running into. 20:17:23 Greg yes. every month sometimes every week, depends on the target audience and what's the qualification overhead (which can vary widely) 20:17:42 <GregNoel> A minor release every month just seems too often. I don't upgrade my software anything like that often 20:18:11 True, but if you have a bug and it's fixed in the next release, do you care what it's called? 20:19:06 <GregNoel> well, depends on the bug, but it wouldn't surprise me to have to wait for more than a month for the next release 20:19:18 but would that make you "happy"? 20:19:56 <GregNoel> I don't see what you're trying to make me say. It makes me neither happy nor unhappy 20:19:57 The main reason people in my space make frequent releases is because it makes the customers happy, they have sufficient tests and resources to do a full test run that frequently. 20:20:50 <GregNoel> So, how often does, say, Debian make a release? 20:21:06 So if there's two products, say cmake and scons, and one of them releases bug fixes with greater regularity, rather than waiting say 3 months for a feature release arbitrarily, one will get greater mind share in the community. 20:21:20 Debian is a HUGH product and not one which makes sense to compare scons with. 20:21:29 HUGE sorry. 20:21:54 <GregNoel> I see your point, but a release takes resources at both ends, so doing it too often doesn't make a lot of sense 20:22:13 agree, i guess we're disagreeing about what is "too often" 20:22:17 True. Too often. Then you end up only releasing and not doing work. 20:22:26 A SCons release takes a few hours of work right? 20:22:53 <GregNoel> It seems to take Steven at least a full working day 20:23:01 <GregNoel> more like two 20:23:12 that's just my lack of organizational ability / juggling other things 20:23:28 i kick off a build / test, start doing other things, take too long to get back to it... 20:23:35 Steven - how much clock time do you think? 20:23:37 end-to-end, it can definitely be done in a few hours 20:23:47 ok. 20:24:25 so 2 hours every month (give or take) to do monthly release. Esp once we get a handful of others able to do the releases, shouldn't be too much of a burden? 20:24:33 if you skip the tests (i.e. trust the ongoing branch testing) and don't word-smith the announcement the way I do, could probably be in one hour 20:24:50 I think those are important tasks which shouldnt' be skipped. 20:24:54 (my 2cents) 20:25:12 <GregNoel> We need to add testing for checkpoint branch, but I think they're necessary. 20:25:32 <GregNoel> That's one reason we have a checkpoint branch, after all 20:25:42 <GregNoel> i.e., buildbot 20:25:52 agreed 20:26:09 yup. http://gallery.deeganworld.net:8010/ (Steven did you get a chance to change the A record?) 20:26:16 larger point: the wall-clock time to release shouldn't be a deciding factor on our frequency 20:26:22 CNAME 20:26:25 no, i haven't 20:26:30 ok. no worries. 20:26:49 also, my home system is still down 20:27:00 we have comcast, but the space where it's going to be set up is still full of boxes.. :-( 20:27:05 Steven - I think Greg has a point, though it doesn't apply to 2 hrs, that if it takes a long time say 1/2 the release frequency, then it's too often. 20:27:16 :) 20:27:45 okay, i agree with that 20:28:25 still leaves us deciding how often, and what to name them 20:28:35 Greg are you o.k. with 1.1 or 1.0.2 depending on what gets checked in during the next 3 weeks? (Does that seem reasonable given this discussion?) 20:28:48 I think monthly is good, naming depending on content. 20:29:09 that gives predictability to the users/developers, and flexibility to name appropriate to what the content is. 20:29:10 <GregNoel> I think the next release should be two months, but there should be approximiately bi-weekly checkpoints 20:29:40 Greg - so we got you down from 3months to 2 months? :) so we're 1/3 of the way there. 20:30:12 half way! 20:30:13 <GregNoel> No, I always wanted two months; there was a discussion on the mailing list that convinced me 20:31:04 <GregNoel> I was assuming the decision was three weeks or three months; Gary made a point that made me think two months would be a better match to what we wanted to do 20:30:42 :) o.k. so once again, why 2 months? is that 2 months for the 1.1 or just 2 months between releases? 20:31:14 <GregNoel> two months for 1.1 20:31:54 <GregNoel> thirty issues from 1.0.1 and 1.0.x plus another dozen from 1.x p1 and other sources 20:32:30 Seems likely that the content for next release will make it a 1.0.2, but say someone has a great idea worthy of 1.1, and we decide to bump stuff to get it in, and/or a new resource pops up with it, then would it make sense to do 1.1 in 1 month? 20:32:30 <GregNoel> That's the focus; if we don't make it, we release with what we have 20:32:58 and scale back the name from 1.1 to 1.0.2, yes? 20:33:16 Greg: Yes I agree. We try and get the 1.0.x bugs done, however if something worthy of 1.1 makes it in, then 1.1 it is? 20:33:32 <GregNoel> 1.0.2 should be bug fixes to regressions; we haven't had any of those; most of the stuff queued up is new features 20:36:19 <GregNoel> sigh. you want three weeks to 1.1, so be it. Is it three weeks to the release candidate or three weeks to the release? 20:37:08 <GregNoel> hello? 20:37:09 3 weeks to candidate, I'm not saying I want the next release to be 1.1, I"m just saying that should something worthy of the 1.1 version be done in that time frame, then it would make sense to label it as such. 20:37:42 <GregNoel> Almost everything I have queued up would meet that criteria. 20:37:50 that we wouldn't (from my point of view) artificially hold off releasing a new feature and/or label it with 1.0.2. 20:38:33 <