-
-
Notifications
You must be signed in to change notification settings - Fork 310
IrcLog2008 09 01
William Deegan edited this page Jan 14, 2016
·
2 revisions
14:02:46 * bdbaddog (n=[bdeegan@adsl-71-131-3-114.dsl.sntc01.pacbell.net](mailto:bdeegan@adsl-71-131-3-114.dsl.sntc01.pacbell.net)) has joined #scons
17:52:09 * garyo-home (n=[chatzill@209-6-158-38.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com](mailto:chatzill@209-6-158-38.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com)) 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. [http://gallery.deeganworld.net:8010/](http://gallery.deeganworld.net:8010/) (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 scons.org ,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=[bdeegan@adsl-71-131-3-114.dsl.sntc01.pacbell.net](mailto:bdeegan@adsl-71-131-3-114.dsl.sntc01.pacbell.net)) has left #scons