IrcLog2008 09 01

William Deegan edited this page Jan 14, 2016 · 2 revisions
14:02:46  *      bdbaddog (n=[]( has joined #scons 
17:52:09  *      garyo-home (n=[]( has joined #scons 
18:34:05  *      stevenknight (n=stevenkn@nat/google/x-9260060d231f4d90) has joined #scons 
18:51:25  <garyo-home>   Hi, Steven. 
18:52:01  *      [GregNoel](GregNoel) is no longer marked as being away 
18:58:29  <stevenknight> hey gary 
19:00:47  <garyo-home>   Just you & me so far... 
19:01:19  <[GregNoel](GregNoel)>     No, I'm here 
19:01:30  <garyo-home>   Ah, hi Greg! 
19:01:32  <[GregNoel](GregNoel)>     just getting a soda 
19:01:50  <stevenknight> hey 
19:02:18  <[GregNoel](GregNoel)>     Anybody else here for the bug party? 
19:02:11  <garyo-home>   Hope everybody's had a good holiday. 
19:02:39  <[GregNoel](GregNoel)>     More than a holiday for us; _three_ birthdays to celebrate... 
19:02:45  <stevenknight> ? 
19:02:48  <garyo-home>   Wow! 
19:02:50  <stevenknight> wow 
19:03:05  <[GregNoel](GregNoel)>     not to mention baby-sitting 
19:03:01  <garyo-home>   kids or grownups? 
19:03:41  <[GregNoel](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  <garyo-home>   Sounds like a big party. 
19:04:26  <[GregNoel](GregNoel)>     multiple rounds of parties; I've been stuffed this weekend 
19:04:44  <[GregNoel](GregNoel)>     and I can't wait for Tuesday so I can get some rest... 
19:04:49  <garyo-home>   :-) 
19:04:42  <garyo-home>   I took my son sailing for the first time (he's 9).  First time with him actually crewing at least. 
19:05:01  <[GregNoel](GregNoel)>     You sail? 
19:05:09  <garyo-home>   Just a little -- small boats. 
19:05:24  <stevenknight> very cool 
19:05:27  <garyo-home>   Would like to do more, but have neither time nor money. 
19:05:28  <stevenknight> i love those growing-up milestones 
19:05:32  <[GregNoel](GregNoel)>     I used to sail Sabots and others of that class, but it's been a while 
19:05:42  <garyo-home>   Carl (my son) was pretty excited. 
19:05:53  <[GregNoel](GregNoel)>     It's a lot of fun... 
19:06:36  <garyo-home>   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](GregNoel)>     Yes, a Sabot is about two meters 
19:07:08  <[GregNoel](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  <garyo-home>   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](GregNoel)>     Maybe someday.... 
19:08:03  <garyo-home>   Saving for retirement... 
19:08:20  <[GregNoel](GregNoel)>     Retirements turn out to be for the great-nephews.... 
19:08:32  <garyo-home>   Hmm, yes I can see how that could work. 
19:08:20  <garyo-home>   OK, shall we get started? 
19:08:23  <[GregNoel](GregNoel)>     yes 
19:08:53  <garyo-home>   So we're starting with the current issues, right?  131 first? 
19:08:58  <garyo-home>   Sorry I mean 2131 
19:09:21  <[GregNoel](GregNoel)>     yes.  I'll go along with sorting it; Steven makes a good point. 
19:09:17  <garyo-home>   I'm happy to do it since I want it to sort. 
19:09:32  <[GregNoel](GregNoel)>     works for me 
19:09:45  <stevenknight> okay, 2131 1.1 
19:09:55  <[GregNoel](GregNoel)>     pri? 
19:10:05  <stevenknight> p2 or p3 ? 
19:10:12  <garyo-home>   p2 ok? 
19:10:23  <[GregNoel](GregNoel)>     It ought to be simple; p2 to get it done 
19:10:33  <stevenknight> 2131 1.1 p2 
19:10:33  <stevenknight> done 
19:10:33  <garyo-home>   agreed 
19:10:38  <[GregNoel](GregNoel)>     done 
19:10:56  <stevenknight> 1307:  consensus patch, 1.1, Ludwig 
19:11:05  <[GregNoel](GregNoel)>     1307 consensus 
19:10:59  <stevenknight> p...3? 
19:11:13  <[GregNoel](GregNoel)>     Hmmm... p2 
19:11:28  <stevenknight> okay p2 
19:11:34  <stevenknight> done 
19:11:46  <[GregNoel](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  <garyo-home>   I don't care p2 or p3... I'll say p3 to let other things bubble up more. 
19:12:19  <[GregNoel](GregNoel)>     either works, he has relatively little to do 
19:12:36  <stevenknight> 1.0.1 has left the station as far as i'm concerned 
19:12:56  <[GregNoel](GregNoel)>     well, the comment was for last week, which didn't happen... 
19:12:59  <stevenknight> (i'm getting into this move-the-release-along mindset... :-)) 
19:13:10  <[GregNoel](GregNoel)>     that's a _good_ thing! 
19:13:25  <stevenknight> exactly 
19:13:29  <stevenknight> so... on to 1973: 
19:13:59  <[GregNoel](GregNoel)>     Gary, the src_dir in your comment is redundant. 
19:14:02  <stevenknight> Greg, I see your point about the semantics being not well thought out 
19:14:16  <stevenknight> but there's a legitimate use case that it does solve 
19:14:23  <garyo-home>   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](GregNoel)>     I was wrong when I wrote it, hadn't checked; the new manpage patch fixes that 
19:15:20  <garyo-home>   Steven: agree we shouldn't remove the functionality.  In the med-long term, should fix it if possible. 
19:15:24  <[GregNoel](GregNoel)>     stevenknight, what use case? 
19:15:35  <[GregNoel](GregNoel)>     I couldn't find one. 
19:15:54  <stevenknight> you can't put a SConscript file in a directory because you don't own it 
19:16:03  <stevenknight> e.g. it's pulled from a repository into which you can't drop files 
19:16:11  <stevenknight> but you still need to build that module for inclusion in your software 
19:16:30  <stevenknight> the *idea* is that you should be able to set src_dir to point to that directory 
19:16:31  <garyo-home>   Oho, that is very interesting!  I have a couple of those myself! 
19:16:43  <stevenknight> and the build happens *as if* the SConscript file lived in the src_dir 
19:16:44  <[GregNoel](GregNoel)>     Use a parallel tree in front of the repository; I do that all the time 
19:17:05  <garyo-home>   Greg: example? 
19:18:20  <[GregNoel](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  <garyo-home>   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](GregNoel)>     stevenknight, I'm thinking about your case, and I'm not sure it works as you expect 
19:19:35  <stevenknight> agreed, it probably doesn't in all cases 
19:19:45  <[GregNoel](GregNoel)>     garyo-home, yes, that's how I SConfiscate third-party stuff I want to use 
19:19:46  <stevenknight> it does for the use cases in the tests of src_dir, though 
19:20:06  <garyo-home>   Greg: if src_dir worked as steven suggested, it would be pretty nice though.  But that's another ticket. 
19:20:12  <[GregNoel](GregNoel)>     I'll have to try xxxx ah, doorbell, hang on 
19:20:24  <stevenknight> i also agree that generalizing this by using a flavor of Repository would probably end up much simpler 
19:20:48  <stevenknight> garyo:  any chance you could let Google fly you out here for the GSoC mentor summit? 
19:20:53  <stevenknight> i know you're really busy... 
19:21:01  <garyo-home>   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  <stevenknight> 1973:  i say do nothing for now 
19:21:32  <stevenknight> let src_dir die when [VariantDir](VariantDir)() dies 
19:21:42  <garyo-home>   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  <stevenknight> yes 
19:22:45  <garyo-home>   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](GregNoel)>     I'm back; give me a chance to catch up 
19:24:27  <stevenknight> okay 
19:25:47  <garyo-home>   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  <stevenknight> eh, now i have to go check... :-) 
19:26:17  <[GregNoel](GregNoel)>     I think my test cases died in our power failure, but I can try to recreate them 
19:26:49  <[GregNoel](GregNoel)>     The summit is 25 October for the weekend 
19:27:05  <garyo-home>   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](GregNoel)>     We're planning to drive up, wrap a little holiday around it 
19:27:35  <garyo-home>   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  <stevenknight> no problem 
19:28:32  <[GregNoel](GregNoel)>     Assuming we're invited, of course... 
19:28:30  <stevenknight> greg, you okay with letting src_dir be until we can replace [VariantDir](VariantDir)() with a generalized Repository interface? 
19:29:22  <[GregNoel](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  <garyo-home>   :-) 
19:30:10  <stevenknight> fair point 
19:30:13  <[GregNoel](GregNoel)>     For one thing, [VariantDir](VariantDir) creates new filesystem space, Repository doesn't 
19:30:42  <garyo-home>   OK, so how about we save 1973 for discussion of what src_dir should/could be, but defer it. 
19:31:22  <[GregNoel](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  <stevenknight> okay 
19:31:35  <stevenknight> don't hold your breath... :-) 
19:31:39  <stevenknight> 2087: 
19:32:03  <garyo-home>   consensus 1.x p3 ludwig, right? 
19:32:03  <stevenknight> consensus 1.x p3 ludwig 
19:32:03  <[GregNoel](GregNoel)>     consensus 
19:32:04  <stevenknight> yes 
19:32:04  <[GregNoel](GregNoel)>     yes 
19:32:16  <[GregNoel](GregNoel)>     done 
19:32:24  <stevenknight> 2183:  i'm okay with 1.0.x 
19:32:26  <[GregNoel](GregNoel)>     2183 
19:32:44  <garyo-home>   2183: didn't read carefully enough to make sure this wouldn't have unintended consequences.  Either of you? 
19:33:06  <garyo-home>   (But it looks fine in the quick read I gave it.) 
19:33:39  <[GregNoel](GregNoel)>     All it does is add a suffix.  I don't know what .sx is, but it appears harmless otherwise. 
19:34:06  <garyo-home>   ok then. 
19:34:13  <[GregNoel](GregNoel)>     who? 
19:34:35  <stevenknight> not me! 
19:34:35  <garyo-home>   I'll do it. 
19:34:35  <[GregNoel](GregNoel)>     Not seeing any volunteers, I'll do it 
19:34:49  <[GregNoel](GregNoel)>     Ah, a little overlap 
19:35:16  <[GregNoel](GregNoel)>     Gary, I may have more spare time over the next couple of weeks 
19:35:35  <garyo-home>   OK, it's yours then.  That's not a sentence I would be likely to utter. :-/ 
19:36:02  <[GregNoel](GregNoel)>     {;-} 
19:36:03  <garyo-home>   How about 2184, a little more interesting? 
19:36:27  <stevenknight> :-) 
19:37:12  <garyo-home>   I'm w/ Steven on 2184.  1.1, p3, accept patch as is.  I'll do it. 
19:38:03  <[GregNoel](GregNoel)>     OK, I guess I missed the issue.  SCons should normally duplicate LIBPATH entries when using [VariantDir](VariantDir) or Repository 
19:38:21  <[GregNoel](GregNoel)>     It'd be a bug if it didn't 
19:38:46  <garyo-home>   You have a point.  But this bug is not about that exactly. 
19:39:16  <[GregNoel](GregNoel)>     OK, I'll let you untangle it 
19:39:22  <garyo-home>   Will do. 
19:39:31  <[GregNoel](GregNoel)>     1.1 p3? 
19:39:44  <garyo-home>   OK. 
19:39:45  <stevenknight> done 
19:39:45  <[GregNoel](GregNoel)>     done 
19:39:59  <stevenknight> 2185:  bill's not here to defend himself... :-) 
19:40:25  <garyo-home>   Greg: I think we agree.  You say wontfix, I say doc, but nobody wants the new function. 
19:40:37  <[GregNoel](GregNoel)>     Concur 
19:40:47  <garyo-home>   I'll try to write up something for 1.x.  P4 ok? 
19:40:52  <[GregNoel](GregNoel)>     works 
19:41:31  <[GregNoel](GregNoel)>     (Bill had the original issue about Explicit, changed to a doc issue, so this really shouldn't be necessary) 
19:42:06  <[GregNoel](GregNoel)>     2166 consensus? 
19:42:10  <garyo-home>   2166: yep 
19:42:17  <stevenknight> yes 
19:42:20  <stevenknight> 2186: 
19:42:34  <garyo-home>   I looked at this, I think it's OK as is. 
19:42:46  <stevenknight> makes sense to me 
19:42:50  <garyo-home>   OP should just use F90PATH. 
19:43:03  <[GregNoel](GregNoel)>     I hadn't found F90PATH, but that makes sense 
19:43:12  <[GregNoel](GregNoel)>     wontfix 
19:43:32  <garyo-home>   It's in the man page, I just checked. 
19:44:46  <[GregNoel](GregNoel)>     hello? 
19:44:49  <garyo-home>   So 2187? 
19:45:19  <[GregNoel](GregNoel)>     2167 consensus? 
19:45:33  <stevenknight> ? 
19:45:42  <garyo-home>   2167 or 2187? 
19:45:44  <stevenknight> what number are we on?  i thought 2186 wontfix 
19:45:47  <[GregNoel](GregNoel)>     oops, 2187 consensus? 
19:45:47  <stevenknight> 2187: 
19:46:53  <[GregNoel](GregNoel)>     teeny, tiny little numbers, can't read them... 
19:45:59  <stevenknight> yes, 1.0.1 greg 
19:46:00  <garyo-home>   2186: consensus wontfix 
19:46:07  <stevenknight> er... 
19:46:39  <garyo-home>   and 2187: consensus 1.0.1 greg (?) 
19:46:51  <stevenknight> yeah 
19:47:04  <stevenknight> 2187:  1.0.1 greg 
19:47:09  <[GregNoel](GregNoel)>     done 
19:47:14  <stevenknight> greg, you can get that in tonight/tomorrow? 
19:47:31  <stevenknight> i'm going to try to turn the checkpoint into 1.0.1 tomorrow (other time commitments allowing) 
19:48:00  <[GregNoel](GregNoel)>     2187? 
19:48:19  <stevenknight> right 
19:48:24  <stevenknight> the [FindFile](FindFile) man page fix? 
19:48:31  <[GregNoel](GregNoel)>     Hmmm...  I should be able to, but no promises... 
19:48:41  <stevenknight> okay, i won't hold up things 
19:48:59  <stevenknight> given the chaos i might not make my target anyway...  :-/ 
19:49:25  <[GregNoel](GregNoel)>     what, a slip already??? 
19:50:04  <[GregNoel](GregNoel)>     2188, consensus 
19:50:21  <garyo-home>   2188: consensus 1.x p4 greg?  (yes, interesting case!) 
19:50:22  <[GregNoel](GregNoel)>     2189, consensus 
19:50:47  <stevenknight> agreed 
19:50:51  <garyo-home>   yes, 2189 too. 
19:51:16  <stevenknight> agreed 
19:51:18  <stevenknight> 2190: 
19:51:30  <stevenknight> not sure here 
19:51:48  <garyo-home>   Steven: you want to make porting autoconf scripts easier, right? 
19:52:01  <garyo-home>   Even if it's basically redundant functionality? 
19:52:25  <[GregNoel](GregNoel)>     I concur with the point, but I don't think this is the issue 
19:52:51  <garyo-home>   Greg: what's the real issue for you? 
19:53:09  <[GregNoel](GregNoel)>     Replacing Configure contexts with something better 
19:53:08  <stevenknight> yeah, it feels like it's more inconsistency the user has to track if they're mentally in autoconf-land 
19:53:22  <stevenknight> and have to do some of the tests completely differently because SCons has Python available 
19:53:25  <garyo-home>   steven: I think I agree, having thought about it. 
19:54:13  <garyo-home>   Greg: point taken, but not a great answer for this ticket.  And anyway, wouldn't we still need an autoconf-syntax-like [CheckFile](CheckFile)()? 
19:54:36  <stevenknight> i think you want one, no matter what the solution ends up looking like 
19:54:58  <garyo-home>   I now think it should be 1.x p4, implemented as Greg suggests. 
19:55:01  <[GregNoel](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  <stevenknight> configuration checks look consistent 
19:55:39  <garyo-home>   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](GregNoel)>     Hmmm... 
19:55:57  <stevenknight> less having to look in the manual for, "wait, how do I do this check vs. that check?" 
19:56:19  <[GregNoel](GregNoel)>     OK, I guess. 
19:57:20  <garyo-home>   OK then.  1.x p4(?) but who?  Can we assign someone else?  Needs test, doc, etc. - more work than implementation. 
19:57:58  <[GregNoel](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  <stevenknight> i do agree with that 
19:58:27  <stevenknight> i forget, this one doesn't come with a patch, does it? 
19:58:57  <[GregNoel](GregNoel)>     I don't think so; he's a newbie 
19:58:55  <stevenknight> no 
19:59:02  <stevenknight> 1.x p4 
19:59:09  <[GregNoel](GregNoel)>     done 
19:59:10  <stevenknight> invite him to submit a patch, ask on the dev list for help, etc. 
19:59:17  <[GregNoel](GregNoel)>     wilco 
19:59:29  <garyo-home>   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  <stevenknight> yeah, not big enough to distract from other important things 
20:00:06  <stevenknight> but might be perfect to get a newbie more involved 
20:00:11  <[GregNoel](GregNoel)>     OK, that closes this spreadsheet.  On to the discussion? 
20:00:15  <garyo-home>   OK, that's the whole new issue sheet. 
20:00:26  <stevenknight> yeah 
20:00:28  <garyo-home>   Yes, 1.0.2 vs. 1.1, right? 
20:00:31  <stevenknight> here's my thinking 
20:00:42  <stevenknight> doesn't seem like we have any burning fires that would require a 1.0.2 
20:00:50  <[GregNoel](GregNoel)>     yes 
20:00:50  <garyo-home>   agreed 
20:01:04  <stevenknight> so the next release is 1.1 in three, maybe four weeks 
20:01:10  <stevenknight> with whatever we can fit 
20:01:14  <[GregNoel](GregNoel)>     too short 
20:01:34  <stevenknight> it's too short only if you're trying to fit a specific set of features into it 
20:01:34  <[GregNoel](GregNoel)>     I'd like to shoot for a 1 Nov release of 1.1 
20:01:47  <garyo-home>   3/4 wks too short for all the issues marked 1.x, but we could subset them? 
20:01:55  <[GregNoel](GregNoel)>     so a RC checkpoint a week ahead of that 
20:01:58  <stevenknight> right 
20:02:09  <stevenknight> 3 weeks RC checkpoint, 4 weeks 1.1 
20:02:15  <stevenknight> with whatever fits w/in 3 weeks 
20:02:26  <[GregNoel](GregNoel)>     There are about 20 issues in 1.0.1 and 1.0.x 
20:02:39  <[GregNoel](GregNoel)>     no way we could do them in a month 
20:03:07  <[GregNoel](GregNoel)>     including the ones already slated for 1.1, plus a few from 1.x p1 
20:04:05  <stevenknight> so if we don't do them all in a month, what's the real harm? 
20:05:02  <[GregNoel](GregNoel)>     oops, that's _30_ issues, I typoed 
20:05:17  <garyo-home>   (I hate tigris's bug tracker formatting, can never find what I want.) 
20:05:48  <[GregNoel](GregNoel)>     You can can bookmark queries 
20:06:27  <garyo-home>   Yes, I need a good set of those.  Wish I could title them too.  But anyway... 
20:05:38  <[GregNoel](GregNoel)>     I thought you could change the title in Firefox? 
20:06:51  <[GregNoel](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  <stevenknight> okay 
20:07:19  <[GregNoel](GregNoel)>     (Actually I put the queries on my home page in my wiki...) 
20:07:48  <garyo-home>   good idea! 
20:07:59  <stevenknight> 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  <garyo-home>   Steven: do you have some issues that need to be fixed soon for your customers? 
20:08:34  <[GregNoel](GregNoel)>     If you release too often, people stop upgrading 
20:08:53  <bdbaddog>     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  <garyo-home>   I just think not much will have changed significantly in 3 weeks (but I'll do my best) 
20:09:11  <[GregNoel](GregNoel)>     it's too much hassle to keep upgrading every month 
20:09:25  <bdbaddog>     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  <stevenknight> no one's forcing anyone to upgrade every month 
20:09:28  <[GregNoel](GregNoel)>     Hi, Bill 
20:09:31  <garyo-home>   Hi Bill! 
20:09:37  <bdbaddog>     Hi. 
20:09:40  <stevenknight> just because you "release early, release often" 
20:09:46  <bdbaddog>     So I may actually agree with Greg on this one.. 
20:09:49  <bdbaddog>     :) 
20:10:03  <stevenknight> shock!  horror! drama! 
20:10:06  <[GregNoel](GregNoel)>     but the one-decimal releases are intended to be places where people upgrade 
20:10:07  <bdbaddog>     unless theres a significant feature, 1.1 may not make sense. 
20:10:19  <garyo-home>   So call it 1.0.2 then? 
20:10:42  <stevenknight> well, i guess the question is whether we're going to be feature-driven or date-driven, then... 
20:10:44  <bdbaddog>     I think so, unless there's a bug fix scheduled which is a notable feature. 
20:10:48  <[GregNoel](GregNoel)>     "release early, release often" applies to development releases 
20:11:11  <bdbaddog>     You can go date driven releases, but number as I mentioned. 
20:11:39  <bdbaddog>     I think date driven makes real sense, although you may end up needing feature or 1.1 devel branch then. 
20:11:46  <stevenknight> okay, so...  how about this... 
20:11:52  <stevenknight> next release is in three weeks 
20:12:06  <stevenknight> but we don't decide on whether it's 1.0.2 or 1.1 until the checkpoint date comes 
20:12:18  <bdbaddog>     depending on what gets fixed/added ? 
20:12:19  <stevenknight> and we decide based on what's actually in there? 
20:12:22  <[GregNoel](GregNoel)>     hmmm... 
20:12:22  <garyo-home>   Right, depending on contents. 
20:12:22  <stevenknight> yes 
20:12:28  <bdbaddog>     sounds good to me. 
20:12:36  <garyo-home>   I can go with that. 
20:12:36  <[GregNoel](GregNoel)>     problem is, one doesn't know what to focus on 
20:12:47  <bdbaddog>     that way we can stay consistant with what version number changes mean. 
20:12:51  <garyo-home>   Highest priority? 
20:12:52  <stevenknight> that's what we're doing here, isn't it? 
20:13:21  <[GregNoel](GregNoel)>     yes, but highest priority has a number of new features 
20:13:52  <garyo-home>   I have to go, guys -- I'll read your decision later. 
20:13:57  <bdbaddog>     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  <bdbaddog>     Gary - Good night to you! 
20:14:08  <stevenknight> 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](GregNoel)>     three weeks implies 1.0.2 but new features implies 1.1 
20:14:13  <garyo-home>   g'night. 
20:14:17  <[GregNoel](GregNoel)>     G'night 
20:14:26  <stevenknight> if three weeks implies 1.0.2 what *does* imply 1.1? 
20:14:40  <[GregNoel](GregNoel)>     two or three months 
20:14:45  <bdbaddog>     Greg: Three weeks doesn't imply 1.0.2 nor 1.1, just a time frame for next release. 
20:14:51  <stevenknight> with no intervening release? 
20:15:12  <stevenknight> 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  <bdbaddog>     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  <bdbaddog>     No real issue (for the most part) with customers accepting it. 
20:15:40  <[GregNoel](GregNoel)>     But how frequent are the releases? 
20:15:51  <bdbaddog>     monthly sounds like to me? 
20:15:53  <stevenknight> ~ monthly 
20:15:54  <stevenknight> yes 
20:16:52  <[GregNoel](GregNoel)>     bdbaddog, I meant how often are the commercial releases.  Not every month, I'm sure 
20:16:56  <bdbaddog>     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  <bdbaddog>     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](GregNoel)>     A minor release every month just seems too often.  I don't upgrade my software anything like that often 
20:18:11  <bdbaddog>     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](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  <bdbaddog>     but would that make you "happy"? 
20:19:56  <[GregNoel](GregNoel)>     I don't see what you're trying to make me say.  It makes me neither happy nor unhappy 
20:19:57  <bdbaddog>     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](GregNoel)>     So, how often does, say, Debian make a release? 
20:21:06  <bdbaddog>     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  <bdbaddog>     Debian is a HUGH product and not one which makes sense to compare scons with. 
20:21:29  <bdbaddog>     HUGE sorry. 
20:21:54  <[GregNoel](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  <stevenknight> agree, i guess we're disagreeing about what is "too often" 
20:22:17  <bdbaddog>     True. Too often. Then you end up only releasing and not doing work. 
20:22:26  <bdbaddog>     A SCons release takes a few hours of work right? 
20:22:53  <[GregNoel](GregNoel)>     It seems to take Steven at least a full working day 
20:23:01  <[GregNoel](GregNoel)>     more like two 
20:23:12  <stevenknight> that's just my lack of organizational ability / juggling other things 
20:23:28  <stevenknight> i kick off a build / test, start doing other things, take too long to get back to it... 
20:23:35  <bdbaddog>     Steven - how much clock time do you think? 
20:23:37  <stevenknight> end-to-end, it can definitely be done in a few hours 
20:23:47  <bdbaddog>     ok. 
20:24:25  <bdbaddog>     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  <stevenknight> 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  <bdbaddog>     I think those are important tasks which shouldnt' be skipped. 
20:24:54  <bdbaddog>     (my 2cents) 
20:25:12  <[GregNoel](GregNoel)>     We need to add testing for checkpoint branch, but I think they're necessary. 
20:25:32  <[GregNoel](GregNoel)>     That's one reason we have a checkpoint branch, after all 
20:25:42  <[GregNoel](GregNoel)>     i.e., buildbot 
20:25:52  <stevenknight> agreed 
20:26:09  <bdbaddog>     yup. []( (Steven did you get a chance to change the A record?) 
20:26:16  <stevenknight> larger point:  the wall-clock time to release shouldn't be a deciding factor on our frequency 
20:26:22  <stevenknight> CNAME 
20:26:25  <stevenknight> no, i haven't 
20:26:30  <bdbaddog>     ok. no worries. 
20:26:49  <stevenknight> also, my home system is still down 
20:27:00  <stevenknight> we have comcast, but the space where it's going to be set up is still full of boxes..  :-( 
20:27:05  <bdbaddog>     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  <bdbaddog>     :) 
20:27:45  <stevenknight> okay, i agree with that 
20:28:25  <stevenknight> still leaves us deciding how often, and what to name them 
20:28:35  <bdbaddog>     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  <bdbaddog>     I think monthly is good, naming depending on content. 
20:29:09  <bdbaddog>     that gives predictability to the users/developers, and flexibility to name appropriate to what the content is. 
20:29:10  <[GregNoel](GregNoel)>     I think the next release should be two months, but there should be approximiately bi-weekly checkpoints 
20:29:40  <bdbaddog>     Greg - so we got you down from 3months to 2 months? :) so we're 1/3 of the way there. 
20:30:12  <stevenknight> half way! 
20:30:13  <[GregNoel](GregNoel)>     No, I always wanted two months; there was a discussion on the mailing list that convinced me 
20:31:04  <[GregNoel](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  <bdbaddog>     :) 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](GregNoel)>     two months for 1.1 
20:31:54  <[GregNoel](GregNoel)>     thirty issues from 1.0.1 and 1.0.x plus another dozen from 1.x p1 and other sources 
20:32:30  <bdbaddog>     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](GregNoel)>     That's the focus; if we don't make it, we release with what we have 
20:32:58  <stevenknight> and scale back the name from 1.1 to 1.0.2, yes? 
20:33:16  <bdbaddog>     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](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](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](GregNoel)>     hello? 
20:37:09  <bdbaddog>     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](GregNoel)>     Almost everything I have queued up would meet that criteria. 
20:37:50  <bdbaddog>     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  <[GregNoel](GregNoel)>     If you're going to let non-regressions in, just call it 1.1 and be done with it. 
20:39:37  <bdbaddog>     I think we can wait til RC to decide what to call it. That's what I'm trying to convince you. :) 
20:40:20  <[GregNoel](GregNoel)>     If you force me to make that choice, I'm not going to put in any non-regressions to leave our options open.  If you want non-regressions in, call it 1.1 
20:41:13  <bdbaddog>     So the process is make the change, submit the patch for review on dev list, then people critique, and then get the go ahead right? 
20:42:10  <[GregNoel](GregNoel)>     sure, as always.  But I won't submit non-regression patches to a potentially bug-fix release. 
20:42:18  <bdbaddog>     So, yes, likely we go ahead and check in regressions, and the release team can decide on what non regression fixes get in. 
20:42:32  <bdbaddog>     you can send the review mail, and the release team can decide? 
20:43:13  <[GregNoel](GregNoel)>     That would imply that the release team actually commented on the bugs.  Only rarely do they. 
20:43:50  <[GregNoel](GregNoel)>     And most of the time, I check stuff in immediately after I post the review so I can start work on the next one. 
20:44:06  <bdbaddog>     Valid point, though my patches usually do (and rightly so, since I'm the newbee). 
20:44:25  <bdbaddog>     So you're working with just one client then? 
20:44:34  <[GregNoel](GregNoel)>     One client? 
20:44:39  <bdbaddog>     sandbox 
20:45:13  <[GregNoel](GregNoel)>     Oh, no, I have multiple sandboxes, but I create the reviews in a common area so I'm sure it's correct. 
20:45:34  <bdbaddog>     I see, to insure they don't conflict? 
20:45:37  <[GregNoel](GregNoel)>     yes 
20:46:57  <[GregNoel](GregNoel)>     Have we lost Steven? 
20:46:59  <bdbaddog>     I see, o.k. Ahhh.. o.k. since you're not necessarily submiting at that time..and therefore can't sync your other sandboxes to verify they work.  hmm.. time for bazaar or a DRCS 
20:47:22  <[GregNoel](GregNoel)>     off-topic for tonight 
20:47:31  <bdbaddog>     yup. true. 
20:48:00  <bdbaddog>     hmm Steven's still signed on. Donno. 
20:48:07  <[GregNoel](GregNoel)>     So what should I start checking in? 
20:48:26  <bdbaddog>     Seems like regressions, and then review emails for non-regressions, would be my vote. 
20:49:09  <bdbaddog>     That would let you work in a non-regression sandbox(es), and sync with your regression checkins to make sure the non-regression fixes aren't broken? 
20:49:17  <[GregNoel](GregNoel)>     Sigh.  I may have one regression ready, but the others are all new features, so just the one, huh? 
20:49:44  <bdbaddog>     Float the non-regressions for review, and at least I'll promise to chime in.. :) 
20:50:19  <[GregNoel](GregNoel)>     Honestly, I see no reason to submit a review unless it's about to be applied.  They age entirely too quickly. 
20:50:23  <bdbaddog>     Likely they'll go in if they're done, and then it'll be come 1.1 
20:50:52  <bdbaddog>     true and they are about to be applied. Unless theres a real reason not to. 
20:51:09  <[GregNoel](GregNoel)>     then it's a 1.1.  call it that now. 
20:51:21  <bdbaddog>     works for me if you've got the patches ready. 
20:51:37  <[GregNoel](GregNoel)>     yes, I do. 
20:52:00  <[GregNoel](GregNoel)>     OK, 1.1 RC in three weeks, release a week later? 
20:52:07  <bdbaddog>     yup. 
20:52:10  <[GregNoel](GregNoel)>     Any intermediate checkpoints? 
20:52:28  <[GregNoel](GregNoel)>     I'd like one in ten days or so. 
20:52:32  <bdbaddog>     Every check in generates a checkpoint (once Steven's machine's online) 
20:52:41  <[GregNoel](GregNoel)>     Not true. 
20:52:48  <bdbaddog>     I'll work with Steven to get automation back up. 
20:53:01  <bdbaddog>     ahh. you mean posted to ,etc. 
20:53:18  <[GregNoel](GregNoel)>     A checkpoint only occurs when someone (Steven) prepares it; it's a separate branch 
20:53:29  <bdbaddog>     o.k. every 10 days sounds reasonable. 
20:53:57  <bdbaddog>     I'll work with Steven to qualify one of my machines for such a task. 
20:54:12  <[GregNoel](GregNoel)>     Sigh.  I wanted bi-weekly checkpoints with a release in two months, but I'll live with this. 
20:54:30  <bdbaddog>     Thanks for being flexible. 
20:54:52  <bdbaddog>     No doubt if it's bad we'll get feedback from user comunity. 
20:55:00  <bdbaddog>     But I think this will be o.k. with them. 
20:55:12  <bdbaddog>     At least my clients will be o.k. with it. 
20:55:15  <[GregNoel](GregNoel)>     Flexible?  Hardly; it's the consensus process.  Majority rules once everyone agrees that their position has been understood by all. 
20:55:40  <bdbaddog>     In theory, but doesn't always work that way if there's bad apples out there. 
20:55:42  <[GregNoel](GregNoel)>     OK, we'll see how it goes; I still think it's the wrong choice. 
20:56:11  <[GregNoel](GregNoel)>     It works for IEEE, even in practice. 
20:56:26  <bdbaddog>     :) 
20:58:52  <[GregNoel](GregNoel)>     My calendar says three weeks is 22 Sep; four weeks is 29 Sep 
20:56:48  <bdbaddog>     Thanks Greg. I've gotta do a little work before I turn in for the night. Did I hear you might be up here in Oct? 
20:57:37  <[GregNoel](GregNoel)>     If SCons is invited.  There're still some impediments to that, but hopefully we can clear them up in time. 
20:58:18  <stevenknight> yep, that ball's in my court 
20:58:32  <bdbaddog>     O.k. If you make it up here, next meals on me. Also we'll arrange a bay area scons thing and you can meet some more of the folks if you'd like. 
20:58:34  <stevenknight> greg, anything in addition to that paperwork? 
20:58:37  <stevenknight> that you know of? 
20:59:00  <[GregNoel](GregNoel)>     Hi, welcome back 
20:59:15  <stevenknight> hi 
20:59:25  <stevenknight> lot going on here... 
20:59:46  <bdbaddog>     :) 
20:59:59  <[GregNoel](GregNoel)>     No, but there's been feedback on the mailing list that the hoops are not as obvious as one could hope.  And the instructions are not as good as they could be.  It'll take longer than you expect. 
21:00:05  <stevenknight> bdbaddog:  getting an Ubuntu machine ready for building / releasing should be a snap now 
21:00:27  <stevenknight> i checked in scripts that should set things up appropriately 
21:00:36  <stevenknight> at least avoid the what-packages-do-I-need hell 
21:00:49  <bdbaddog>     o.k. I'll give em a try this week. I think my laptops setup at this point for linux. 
21:00:54  <stevenknight> i used a VM that i populated with the script to do that last checkpoint release 
21:02:15  <[GregNoel](GregNoel)>     Comment in passing: I've got the buildbot stuff on my OS X platform, but it's still shaky.  I'll probably be asking for a username/password soon to connect with the existing system. 
21:02:36  <stevenknight> cool 
21:03:55  <[GregNoel](GregNoel)>     OK, my wife has waited long enough to watch the Olympics closing.  We [TiVoed](TiVoed) it and have been gradually catching up.  See you later 
21:04:05  <stevenknight> later greg -- thanks 
21:04:13  *      [GregNoel](GregNoel) has been marked as being away 
21:04:20  *      stevenknight has quit ("Leaving") 
21:05:59  *      garyo-home has quit ("[ChatZilla](ChatZilla) 0.9.83 [Firefox 3.0.1/2008070208]") 
21:16:48  *      bdbaddog (n=[]( has left #scons 

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.