Skip to content
garyo edited this page Dec 13, 2014 · 3 revisions

16:03:04 * techtonik (chatzilla@mm-127-247-57-86.leased.line.mgts.by) has joined #SCONS 16:31:51 * garyo (garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS 16:47:50 * bdbaddog (chatzilla@207.88.181.2.ptr.us.xo.net) has joined #SCONS 17:00:39 * sgk (sgk@nat/google/x-bfuzncsvocbkaddk) has joined #SCONS 17:00:48 Hi guys 17:00:53 * You are no longer marked as being away 17:00:53 hello hello 17:00:57 * GregNoel is here 17:01:07 Hi Greg 17:01:14 <GregNoel> Hello, everyone; who all is here? 17:01:29 * sgk applauds GregNoel for getting 2.0.0 release 17:01:30 Looks like me, sgk, Bill, you 17:01:32 d 17:01:36 I'm here. 17:01:58 * Jason_at_Intel (chatzilla@12.18.240.224) has joined #SCONS 17:02:00 Yes -- kudos to both Greg and Bill for getting through a lot of checkpoints and releases recently! 17:02:04 Hi Jason 17:02:15 Garyo: Thanks. 17:02:17 <Jason_at_Intel> HI all 17:02:34 I guess 1.3.1 should go out soon. I'll get it done when I'm back from this conference. 17:02:20 <GregNoel> sgk, garyo, thanks. We had a major earthquake leading to lots of network outages that made the process interesting... 17:02:29 yow 17:02:37 Oh yeah, I heard about that -- no major damage though? 17:03:10 <GregNoel> garyo, not to us. A picture fell off a shelf and broke the glass. 17:03:24 <Jason_at_Intel> ? 17:03:37 I thought people in California didn't put things on shelves :-/ 17:03:45 (earthquake, Jason) 17:03:55 <Jason_at_Intel> ahh 17:04:07 <GregNoel> There are bookcases in our library. 17:04:32 So wow, 2.0 is out and all kinds of stuff is now unblocked -- meaning I have to get to all those things I said I'd do post 2.0! :-) :-) 17:04:30 <GregNoel> Anyway, are we ready to go? 17:04:36 Yes, I'm ready. 17:04:41 ready 17:04:46 <GregNoel> 2634, wontfix? 17:05:03 i can go there 17:05:05 I'm ok w/ that, he'll reopen if needed 17:05:14 <GregNoel> done 17:05:16 <GregNoel> 2636, more time? 17:05:20 yes 17:05:34 yes, revisit next bug party 17:05:43 <GregNoel> done 17:05:45 <GregNoel> 2639, consensus 2.1 p3, but needs an owner. 17:05:54 russel brought it up, right? 17:06:21 * sgk wishes that tigris.org's bug tracker had keyboard shortcuts 17:06:30 <GregNoel> {;-} 17:06:33 <Jason_at_Intel> loading spreadsheet.. but ready 17:06:35 Maybe he'd do it. Yes, he posted it. 17:06:53 no wait, Steven did. 17:07:33 yeah, i opened it to avoid another N emails where people debated whether or not an issue should be opened, and by whom 17:06:53 <GregNoel> Or how about techtonik? He's interested in documentation. 17:07:00 Greg: that's a good idea. 17:07:27 <Jason_at_Intel> anyone use the tiris ecplise of VS integration? 17:07:54 jason: not me. 17:08:06 if techtonik is interested, great 17:08:13 OK, for 2639, assign to techtonik & see if he minds? 17:08:19 Or ask first? 17:08:27 <GregNoel> OK, I'll ask him. Is that the decision? 17:08:32 yeah 17:08:33 +1 from me 17:08:45 and if he doesn't want it, then i'm okay with just giving it to Russel 17:08:36 <GregNoel> done 17:08:39 <GregNoel> 2640, consensus 2.1 p2 Greg, unless Gary restores his offer... {;-} 17:08:39 <GregNoel> 2642, consensus 2.1 p3 Gary 17:08:39 <GregNoel> 2643, consensus 2.x p3 Gary (I'm neutral about coercion v. error) 17:08:39 <GregNoel> 2644, Steven, I don't think an organized text file is more of a custom file format than a "standard" XML binary format; quite the reverse, in fact. Besides, I'm leery of requiring another external package to diff XML when all the python versions we support have difflib for text. 17:09:23 re: 2644: okay, suit yourself 17:09:26 2644, I don't have an opinion either way 17:10:36 +1 on not requiring more packages for developer. 17:10:32 2645 I can do, if you don't mind me doing it blind (no Fortran) -- I'll just check with the OP. 17:10:33 <GregNoel> 2645, consensus 2.1 p2, but needs an owner. 17:11:01 I'll take it 17:11:30 <GregNoel> done 17:11:33 <GregNoel> 2646, consensus invalid 17:11:33 <GregNoel> 2647, Steven solved a nasty problem and checked in a fix, but should that fix be scheduled toward a release of 2.0.0.final.1, 2.0.1, or 2.1? I added a workaround to the issue that should work (Gary's suggestion of SideEffect() works perfectly), so if we deem that good, I vote for 2.1. 17:11:59 what's the difference between 2.0.0.final.1 and 2.0.1 ? 17:12:02 from a user perspective 17:12:21 <GregNoel> sgk, the former is a patch, the latter is a new release. 17:12:41 and users need to know / care about that distinction because...? 17:12:01 Sideffect() is a workaround for the issue right? 17:12:15 <Jason_at_Intel> yep 17:12:09 I vote for 2.1. It's still a corner case. 17:12:46 <Jason_at_Intel> Well as a corner case i can't promote to Scons 1.2+ till it is in 17:12:48 post bugs, I think we need to discuss getting rid of the .final. 17:12:50 Right, we shouldn't drop everything to release this fix basically. 17:12:56 <GregNoel> I'm seeing a consensus toward 2.1 17:12:59 <Jason_at_Intel> I have six products that broke cause of this 17:13:16 it's a regression right? 17:13:21 yes, it worked in 1.2.0 17:13:22 2.0.1 17:13:25 <Jason_at_Intel> yep 17:13:26 <GregNoel> Jason_at_Intel, can you use SideEffect()? 17:13:27 Hm, ok maybe it's an edge rather than a corner? :-) 17:13:34 heh 17:13:47 we have a fix. 2.0.1, unless u think the fix might destability 2.0.0 17:13:56 destabilize that should be. 17:14:12 <Jason_at_Intel> Yes, i have people moving to it... but politics prevent a move to 2.0 cause of fear that something else if wrong 17:14:22 I'm ok either way, just trying to reduce release churn so we can get some work done. 17:14:38 <Jason_at_Intel> I think that SideEffect is more correct in most of the cases this happens for me 17:14:52 Jason: that's what I'd expect, given the testcase. 17:15:02 pushing the release button is all I have time for in the near future. so if I can get a handle on greg's changes I can do that. 17:15:10 <Jason_at_Intel> but the large products have 350 binaries in it 17:15:29 <Jason_at_Intel> so it hard to say that SideEffect will fix all cases developer have come up with 17:16:11 <Jason_at_Intel> we have some very cleaver people :-) 17:16:10 If Bill's got time for a 2.0.1, I'm OK with that. Is there anything else we should squeeze in? 17:16:24 <Jason_at_Intel> I can wait till 2.0.1 17:16:29 maybe any doc changes? 17:16:29 <GregNoel> Sounds to me that you should try to switch to SideEffect() and if it doesn't solve your problems, reopen the question. 17:16:33 <Jason_at_Intel> but i hope it is in 30 or so :-) 17:16:42 30 what? 17:16:48 yeah, doc changes: i still owe a writeup on SConsignFile() 17:16:53 <Jason_at_Intel> 30 days 17:17:05 ok. Yes, I owe some doc fixes too. 17:17:08 I also owe some doc work as well. 17:17:10 <GregNoel> also 17:17:10 --warn in the UG I think. 17:17:48 Steven, I sent you some doc a while ago, any opinion on where that could go? 17:18:00 oh, right 17:18:10 i vaguely remember looking at it and not having a good idea either 17:18:14 same with SConsignFile 17:18:30 if it's really homeless, putting it in the Misc chapter seems as good as any 17:18:12 <GregNoel> (I have a question about the doc work, too, but let's return to it later; resolve this issue first.) 17:18:44 I'm hearing 2.0.1 for this issue. 17:18:58 so 2.0.1 with a normal checkpoint cycle, right? 17:19:06 Jason needs it, it's done, and Bill has time to push it out. 17:19:08 <GregNoel> I'd rather see if SideEffect() solves the problem. 17:19:29 He should use SideEffect where possible anyway; it's more correct. 17:19:39 Ties the dependency to the proper builder. 17:19:34 Jason_at_Intel: what would give your user base the most confidence? 17:19:44 knowing that there's a better solution in the current code base, 17:19:56 or fixing this behavior with Depends()? 17:19:42 GregNoel: But is SideEffect() is a workaround? 17:20:29 Depends() is weird in this case anyway. It's brain-twisting that it even should work. 17:20:31 <GregNoel> Depends() is an accident; SideEffect() is really the right solution. 17:20:49 (but I agree it should work.) 17:20:36 <Jason_at_Intel> I would say 2 things 17:21:13 <Jason_at_Intel> 1) being backwards compatible.. so teh current build does not break ( minus stuff that is really broken) 17:21:20 <Jason_at_Intel> 2) saying that something did not happen.. Scons is very silent on what it is doing 17:21:23 <Jason_at_Intel> ie 17:21:49 <Jason_at_Intel> it does not say .. i am ignoring this node as it has no builders... did you mean SideEffect? 17:21:50 garyo: i kind of view it as Depends() should work on a file without a Builder just like it does on one with 17:21:57 it's just that without a Builder, the build action is null 17:22:20 but that may be because i've been brainwashed by the current implementation 17:22:31 sgk: you're right, I'm kind of exaggerating. But I think everyone's right: 17:22:40 <Jason_at_Intel> people get unhappy when Scons when they don't get why it will not build something as they expect 17:22:43 shuttle real soon.... 17:22:40 <GregNoel> sgk, then will you fix Alias() as well? It has the same problem. 17:22:56 GregNoel: good point 17:23:05 since this behavior is fresh in my mind, i'll take a look now 17:22:55 Depends() should be made to work as it did, and Jason should use SideEffect where it's correct to do so. 17:23:20 <Jason_at_Intel> it is not me... but the developer i support :-) 17:23:22 biab 17:23:23 * sgk has quit (Quit: sgk) 17:23:30 Jason: yep 17:23:40 <Jason_at_Intel> ya the Alias() and Depends() 17:23:43 <GregNoel> brb 17:23:44 <Jason_at_Intel> I like that to be fixed 17:24:02 <Jason_at_Intel> it would allow the Make virtual node idea to work as people expect 17:24:08 Jason: no doubt in anyone's mind they should work. 17:24:54 But do we need to put out an extra release, with checkpoints and bla bla bla, for it? Maybe... let me see how many 2.1 tickets we have. 17:25:18 <Jason_at_Intel> I know... the problem i get is I have some very passionate developer that go back and say " in my day.. this did not happen... and pigs flew" 17:25:35 I'm thinking since we'll be adding a lot into 2.1, that this bug fix should go without all that additional changes. 17:25:45 OK, we have 68 tickets open for 2.1. This is going to take a while. 17:26:10 So maybe 2.0.1 is appropriate. 17:27:09 whoa, 20 of the 2.1 issues are mine :-/ 17:27:33 Yeah. I don't want to even look at that yet..:( 17:27:56 You're OK, only 5. 17:28:16 <GregNoel> As I said before, Depends() is an accident; SideEffect() is really the right solution. The regression should be fixed, but you should be using SideEffect(). 17:29:12 I think we all agree on that now. But looking at the tix for 2.1, I think 2.0.1 is OK if Bill's up for it. 17:29:40 yup. so we do a checkpoint? and then 2weeks later 2.0.1 right? 17:29:44 * Jason_at_Intel has quit (Ping timeout: 260 seconds) 17:29:48 this weekend is when I'll get to the build. 17:30:18 Works for me; I should be able to get some doc in there too by then. 17:30:32 * Jason_at_Intel (chatzilla@12.18.240.224) has joined #SCONS 17:30:55 * sgk (sgk@67.218.105.226) has joined #SCONS 17:31:07 am i back yet? is this thing on? 17:31:08 <GregNoel> It could work. It was surprisingly easy to cherry-pick individual changesets over via checkpoint. But I'd oppose bringing over anything more. (Well, maybe the doc.) 17:31:37 what'd i miss? 17:31:58 <Jason_at_Intel> we agree that we have a lot of stuff to fix 17:32:02 2.0.1 with just that fix, checkpoint build this weekend, 2.0.1 2 weeks later. 17:32:03 I think we're agreeing on 2.0.1 with a checkpoint first, including only this fix and some doc 17:32:10 yes. + doc. 17:32:45 <GregNoel> done 17:32:22 (and that there are 68 tickets open for 2.1, 20 of which are mine, ack) 17:32:27 okay 17:32:48 (the other 48 are probably mine, given my track record... :-/) 17:33:14 Actually a bunch are issues@scons which I don't understand 17:33:43 <GregNoel> sgk, 2.1 is scheduled for October, so you've got plenty of time... {;-} 17:34:02 October 2009? :-) 17:34:16 j/k 17:34:20 garyo: don't understand how they got that way? I returned a whole bunch that were languishing with me 17:34:25 <GregNoel> garyo, probably +Easy that never got assigned. 17:34:54 ok, sounds plausible 17:35:01 <GregNoel> garyo, no, October 2010, believe it or not; it's in the roadmap. 17:35:26 excellent! 17:35:51 * sgk scores a point for garyo 17:35:52 68 tickets in 4 months is doable I think. 17:36:07 yep, sounds realistic 17:35:51 <GregNoel> OK, we seem to be agreed on that; resume the doc discussion? 17:35:57 fine w/ me 17:36:58 <GregNoel> My question is where the command-line options live. I was looking for a template to start with while I was waiting for the regression tests to finish and couldn't find one. 17:38:13 in the User's Guide, they kind of just show up wherever it conceptually makes sense to introduce them 17:38:17 * sgk goes to look for an example 17:38:31 <Jason_at_Intel> the is a nice section in the man page 17:38:52 example: --tree= shows up in the troubleshooting section 17:39:26 so it's a matter of thinking about where it makes logical sense to introduce the concept of "you can control warnings" 17:40:10 <GregNoel> Hmmm... I think I have --warn= and Gary has --checkdisk, but neither of them seem to have homes. 17:40:32 there is a chapter that's nominally about controlling your build from the command line 17:40:38 doc/user/command-line.{in,xml} 17:40:57 * GregNoel looks at it... 17:40:59 but it's a little more about Options and stuff like that 17:41:14 but maybe it provides a logical home anyway 17:41:25 i could also see --warn= in the troubleshooting section 17:41:52 i could see users ending up there if they ask themselves, "where do I find out how to get SCons to STFU" 17:42:26 I agree -- the man page is where we put all the options together; the UG should be task-oriented. 17:42:47 <GregNoel> Yeah, either is a possibility; I was afraid I'd have to do an entire new page... 17:44:02 <GregNoel> Now that I have a clue, I'll be able to hunt down a few more examples. Thanks. 17:44:34 okay 17:44:40 what else? 17:44:44 <GregNoel> Anything else? There were some other things about doc before; are all of those answered? 17:45:05 .final ? 17:45:20 <GregNoel> What about it? 17:45:37 Can we omit it, per discussion on the ml today? 17:45:39 Are we going to drop it and have 2.0.1 and 2.0.0,etc for the actual release? 17:45:44 yeah, i was surprised to see that show up in the actual package name 17:45:45 * Jason_at_Intel has quit (Ping timeout: 240 seconds) 17:45:49 well not 2.0.0 since it's out 17:45:55 right 17:46:45 <GregNoel> I noticed that as the release was going out, but I didn't have time to do anything about it then. 17:47:28 ok, for 2.0.1 then, we're all agreed? 17:47:30 <GregNoel> There's a distinction between the package name (.final.) and the release name (2.0.0). 17:47:50 <GregNoel> We need to figure out which is used where. 17:48:00 GregNoel: conceptual distinction, or just in the way I implemented the SConstruct build long long ago? 17:48:09 <GregNoel> Yes 17:48:25 which? 17:48:28 let me ask another way 17:48:54 we all agree the release should ideally be named 2.0.1, not 2.0.1.final, yes? 17:48:59 * Jason_at_Intel_ (chatzilla@12.18.240.224) has joined #SCONS 17:49:00 * Jason_at_Intel_ is now known as Jason_at_Intel 17:49:22 yes 17:49:33 <GregNoel> Yes, but when one refers to the package, it has the suffix. They're different. 17:49:53 that's the next question 17:50:06 <GregNoel> That is, you should download 2.0.1.final.0, but it should install 2.0.1. 17:50:12 GregNoel: you're saying that you think the package should be named scons-2.0.1.final.0.tar.gz ? 17:50:19 <GregNoel> Yes 17:50:34 why? i don't know of another project that does that 17:50:51 does it buy us anything other than the ordering? or is that the main motivator 17:50:57 <GregNoel> Because it sorts alphabetically. 17:51:48 Doesn't seem to be a problem for other projects, so why be diffferent? 17:51:48 i personally don't find that a compelling reason to make users map between the release number and a package with a different name 17:52:03 Irrespective of anything else, I think the download file of 2.0.1 should be called scons-2.0.1.tar.gz unless we have a really good reason. 17:52:11 concur 17:52:38 Checkpoints and betas should identify themselves as such though, just as we've been doing. 17:52:45 <GregNoel> Well, I've missed final releases because it was buried in the list of alpha, beta, ... releases, so I have personal motivation if nothing else. 17:53:14 Still, look around -- nobody else calls their finals final. 17:53:39 * Jason_at_Intel has quit (Ping timeout: 260 seconds) 17:54:17 <GregNoel> I could be persuaded, but I'd still worry about it. 17:54:08 Is either way technically more difficult than the other? 17:54:29 i don't think so, but i haven't looked at that code in a while 17:55:21 <GregNoel> garyo, yes; update-release-info has to know which values to update; it's tricky for the case of pure text files with no hints. 17:54:42 GregNoel: still worry about what aspect of it? 17:56:14 <GregNoel> sgk, people picking the last-listed (or first-listed) simply because they missed the actual release in the middle. 17:56:49 <GregNoel> Look at the RPM labeling to avoid that problem. 17:57:24 ? 17:57:26 Yes, rpm solves that cleverly. But it's not purely alphabetical; it sorts the separate fields. 17:57:23 We can go non-final and see if we get any user issues.. 17:57:34 if not we stay that way, if so we revisit. 17:57:41 There's no good way if sourceforge is purely alpha. 17:58:26 <GregNoel> I'm certainly open to suggestions. 17:58:18 I think people will figure it out. 17:58:51 <GregNoel> garyo, I missed it, more than once. And I think I'm brighter than the average downloader. 17:58:55 I think in the absence of brilliant new methods we should just do what everyone else does. Innovate in the software, not the naming. 17:58:59 So I'm looking at the SF ui now. newest files are at the top. 17:59:35 That would be sensible... 17:59:38 Highlighted in green with a table tile of "newest files" 17:59:49 then a section labelled "all files" 17:59:59 I think we'll be fine with vanilla 2.0.1 labelling. 18:02:08 <GregNoel> OK, identify which cases need the full label and which need the short label, and I'll see what I can do with update-release-info. 18:02:35 Greg's right that in some cases it will probably not sort ideally. But I think it's such a minor thing, and the ".final.0" sticks out like a sore thumb to me; for me it's mostly an aesthetic thing. 18:02:40 alpha, beta, candidate all seem okay with the full label 18:03:30 as a naive user, any added word (or abbreviation like "rc") is a flag to me that it's not a production release 18:04:28 so are we doign alpha and candidate now? or just alpha, beta, and released (where there's no additioinal text for the released version) 18:05:00 <GregNoel> Ah, bad timing; I'm called to dinner. I'll collect my thoughts and continue the thread on the mailing list. 18:05:23 darn, i had a testing topic i wanted to talk about 18:05:30 okay, i can shift that to the mailing list, too 18:05:40 free beers at vendor party are waiting for me... 18:06:04 <GregNoel> I can stall a few minutes for another topic, but this one is drawing out. Is it quick? 18:06:11 probably not 18:06:37 <GregNoel> A quick general statement of the issue? 18:06:40 trying to decide how to start converting the tests 18:06:55 to the new sconstest- prefix idea 18:06:23 float it to release or dev mailing list? 18:07:15 <GregNoel> Ah. Definitely not quick. Mailing list it is. We'd need Dirk for it anyway. 18:07:23 yep, good point 18:07:29 we're done? 18:07:36 <GregNoel> I think so; g'night all. 18:07:40 bdbaddog: i'll send to dev 18:07:41 * You have been marked as being away 18:08:05 'night 18:08:07 ok folks, see you again soon. bdbaddog, have a beer for us! 18:08:14 will do! 18:08:24 * sgk (sgk@67.218.105.226) has left #SCONS 18:08:55 * bdbaddog has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401064631]) 18:09:30 * garyo (garyo@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has left #SCONS

Clone this wiki locally