Clone wiki

SCons / BugParty / IrcLog2008-07-28

19:01:54 <Greg_Noel> Anybody here for the bug party? 19:02:16 <Pankrat1> Yes, me (Ludwig) 19:02:27 <Pankrat1> Good Morning Greg :) 19:03:03 <Greg_Noel> Yeah, I'll bet it's a ghastly hour of the morning; aren't you UTC+1? 19:03:39 <Pankrat1> UTC+2 actually (Daylight saving time) 19:04:04 <Greg_Noel> Sommerzeit... 19:04:19 <Pankrat1> Ja ... but I'm used to work late in the evening if day-work permits 19:05:00 <Greg_Noel> Well, I'm not seeing anyone else... 19:05:30 <Greg_Noel> No Steven, no Bill, no Jim, no Ken (Gary is on holiday) 19:07:38 <bdbaddog> Good day all. 19:07:53 <Greg_Noel> Welcome. 19:08:14 <Pankrat1> Hello Bill 19:08:23 <Greg_Noel> How long can you stay tonight? 19:09:14 <bdbaddog> probly 10-20 minutes. :( 19:10:03 <bdbaddog> not that many bugs on the current issues list. 19:10:16 <Greg_Noel> Ouch. Steven isn't here yet, and since he and I disagree about almost every issue in the spreadsheet, he should be here. 19:10:04 <Pankrat1> Bill: Interesting idea concerning the chunk MD5 shortcut. 19:10:21 <Pankrat1> but it's not done (yet) 19:10:49 <bdbaddog> It should be a pretty effective shortcut at least as far as detecting if includes have changed, since mostly includes are at beginning of files. 19:11:45 <Pankrat1> I have found that a chunk size of 64kb gives best performance. I guess source files mostly fall below that size 19:12:14 <bdbaddog> users could tune to nfs rsize... 19:12:33 <Greg_Noel> 64Kb == large. My first UNIX system had 98Kb... 19:12:43 <bdbaddog> My first home system had 8kb. 19:12:52 <bdbaddog> now my phone has 2GB. 19:12:53 <Greg_Noel> Was it multi-user? 19:13:03 <bdbaddog> nope. commodore pet. 19:13:24 <Greg_Noel> Nice machine; I still have a bunch of Amigas. 19:13:25 <bdbaddog> we had a pdp 11/70 timeshare in highschool. 19:13:40 <bdbaddog> I have an atari 800 in the garage. 19:14:18 <bdbaddog> I'll ping Steven on another IM system. 19:15:08 <Greg_Noel> I was just checking; I thought I had his phone number, but the area code is wrong, so it's probably from before his move. 19:18:52 <Pankrat1> Greg: In the spreadsheet (1646) you mentioned some issues you wondered about? 19:22:23 <Greg_Noel> Yes, direct calculation of the sig. There's supposed to be a subsystem that automagically captures any sig reference and keeps it in the .sconsign file; you seem to be going around that. But I don't know the code well enough to be sure. 19:29:53 <Pankrat1> As far as I understand, the content sig is calculated and stored in the ninfo, which is then pickled eventually. At least there is no change in storing the csig before/after the patch. 19:31:04 <Greg_Noel> As I said, I don't know the code. I just felt that Steven should take a quick look at it. "Eyes on the patch." 19:37:39 * stevenknight (n=stevenkn@nat/google/x-561066767c2a9eb6) has joined #scons 19:37:45 <stevenknight> hey there -- anyone still here? 19:37:51 <Greg_Noel> No, not a soul. 19:38:09 <stevenknight> sorry for the delay, unanticipated emergency... 19:38:23 <Greg_Noel> We were beginning to worry... 19:38:41 <stevenknight> nothing life-threatening, just work... 19:38:51 <Greg_Noel> Bill is off pinging you elsewhere and Ludwig has probably fallen asleep. 19:39:03 <bdbaddog> :) nah I'm here. 19:39:13 <Pankrat1> Still there :) 19:39:38 <Greg_Noel> OK, I think this is good enough for a quorum; shall we proceed? 19:39:58 <stevenknight> ready when everyone else is 19:40:13 <stevenknight> 1646, then? 19:40:16 <Greg_Noel> issue 1646 19:40:45 <stevenknight> good point by Greg re: lack of regression 19:40:50 <Greg_Noel> It's an enhancement, so it can't be 1.0.x, but anything soon after that is good. 19:40:53 <stevenknight> i can go with 1.x p2 19:40:57 <Greg_Noel> done 19:41:02 <stevenknight> 2147: 19:41:08 <Greg_Noel> Ludwig, you OK with that? 19:41:25 <Pankrat1> 1.x is good. Patch review would be good. 19:41:35 <stevenknight> pankrat++ 19:41:45 <bdbaddog> +1 19:41:51 <Greg_Noel> Steven for the code review; I don't know the code. 19:41:58 <stevenknight> 2147: i didn't realize this required batch builders 19:42:04 <stevenknight> (shows how closely I looked...) 19:42:26 <Greg_Noel> Yes, the vala builder is even discussed in 1086 19:42:58 <stevenknight> yeah, 1.x p4 feels right to me 19:43:03 <Greg_Noel> All the sources must be in the command. 19:43:05 <Greg_Noel> done 19:43:10 <stevenknight> 2148: 19:43:48 <stevenknight> hmm, i can go with 1.x p1 19:43:50 <Greg_Noel> Somebody needs to troubleshoot with him and get a test case. Bill? 19:43:56 <stevenknight> if only because 1.0.x is already getting pretty full 19:44:07 <Greg_Noel> More than full, overflowing. 19:44:41 <bdbaddog> I don't even know what the heck vala is? 19:44:41 <bdbaddog> :) 19:44:51 <stevenknight> not vala, we're on 2148 19:44:54 <bdbaddog> yes. we'll ahve to retriage them at somepoint. 19:45:06 <stevenknight> the MSVS_USE_MFC_DIRS thing 19:45:23 <bdbaddog> sure sign me up. I'll trade some emails and get some way to test this problem. 19:45:29 <Greg_Noel> done 19:45:34 <stevenknight> 2148 needs to get pinned down as to whether it's a real regression or a problem in the guy's config 19:45:40 <stevenknight> 2149: 19:46:01 <stevenknight> agree again w/Greg's not-a-regression criteria 19:46:07 <stevenknight> 1.x p1 19:46:10 <Greg_Noel> done 19:46:10 <Pankrat1> 2149: low profit, low risk 1.x low priority 19:46:29 <stevenknight> but a big win for low risk, so high priority... :-) 19:46:39 <Pankrat1> ok :) 19:46:49 <stevenknight> want to make sure it doesn't get shoved off the end of the list by mistake 19:47:07 <Greg_Noel> And a patch gets priority 19:47:27 <stevenknight> 2150: agree that it's not the same fix 19:47:36 <stevenknight> but the problem being described is (i believe) a dup of 1957 19:47:40 <Greg_Noel> better testing++ 19:47:45 <stevenknight> and benoit's fix in 1957 should take care of it 19:47:57 <stevenknight> mind you, that's without any real triage... 19:48:16 <Pankrat1> 2150: looks like a simple race condition to me ?? 19:48:38 <stevenknight> probably 19:48:54 <Greg_Noel> but 1957 is something worse, an error due to the race 19:49:37 <Greg_Noel> How about Ludwig to look at 1957 and see if they're the same? 19:49:49 <stevenknight> sounds good to me, research Ludwig 19:49:54 <Greg_Noel> done 19:50:01 <Pankrat1> ok 19:50:36 <stevenknight> 2151: i think Greg's right, anytime p4 19:50:37 <Greg_Noel> 2151, anytime p4 19:50:43 <Greg_Noel> done 19:50:52 <stevenknight> where "anytime" might include 1.0.x, of course... :-) 19:50:59 <Greg_Noel> yes 19:51:04 <stevenknight> 2152: 19:51:27 <stevenknight> i can go either way 19:51:46 <Greg_Noel> I'd prefer 1.x 19:51:50 <Greg_Noel> p2 19:52:05 <bdbaddog> 1.x 19:52:11 <stevenknight> i put down 1.0.x because i'd just as soon try to get more off our plate sooner when they're pretty easy and low impact 19:52:40 <Greg_Noel> True, but if Mati decides to fix it during 1.0.x, that's fine. 19:52:43 <stevenknight> it'd be one less to have to re-triage for 1.x 19:53:00 <Greg_Noel> (one fewer) 19:53:02 <stevenknight> okay, i can go with that 19:53:05 <bdbaddog> k that's fine by me. 19:53:11 <stevenknight> (true, one fewer) 19:53:23 <Greg_Noel> 1.x p2, then 19:53:56 <stevenknight> if someone has a 1.x issue they want to get in to 1.0.x, then do we re-approve at a weekly? 19:54:46 <Greg_Noel> Send a message to dev saying it's ready; if consensus, then apply. 19:54:54 <bdbaddog> sounds good. 19:54:54 <stevenknight> works for me 19:54:59 <stevenknight> 2153: 19:55:20 <Greg_Noel> Needs a patch, or a better test case 19:55:21 <stevenknight> not a functional regression, but i think it's a pretty serious hidden defect 19:55:44 <stevenknight> good point re: not really knowing the scope of this 19:55:59 <stevenknight> hard to say it definitely must go into 1.0.x unless we can gauge the potential impact 19:56:07 <stevenknight> research? 19:56:15 <Greg_Noel> hmmm, ok, who? 19:56:17 <bdbaddog> yup. 19:56:17 <stevenknight> me 19:56:27 <stevenknight> 2153: research, stevenknight 19:56:34 <Greg_Noel> done, although you've got too many of those now 19:56:40 <bdbaddog> yeah. I could take that one. 19:57:03 <bdbaddog> track down where it's happening see if I can make a testcase, but might have to punt it over for a fix. 19:57:16 <stevenknight> but hey, I actually closed a few after last week! 19:57:27 <stevenknight> :-) 19:57:53 <stevenknight> (or researched and reprioritized, actually) 19:58:04 <stevenknight> don't i get a biscuit for good behavior? 19:58:04 <Greg_Noel> bdbaddog, how are you doing on your current research workload? Don't you still have a few? 19:58:11 <stevenknight> :-) 19:59:01 <bdbaddog> yes. still have some. fortunately (for scons), one of my clients is dropping their hours so I should have some more time in the near term to work onthis stuff. 19:59:46 <Greg_Noel> OK, 2153, research, Bill? 20:00:35 <stevenknight> works for me 20:00:55 <Greg_Noel> done 20:01:00 <stevenknight> 2154: 20:01:16 <stevenknight> any objections to my unilateral prioritization? 20:01:30 <Greg_Noel> not me 20:01:50 <bdbaddog> k folks I'm a pumpkin, gotta run. 20:01:57 <stevenknight> later bill -- thanks 20:02:20 <Greg_Noel> On to 1.0 strategy? 20:02:56 <stevenknight> yep 20:03:03 <Greg_Noel> I've said this before, but to recap: 20:03:03 <Greg_Noel> I think 'branches/core' should be moved to 'trunk', to match the expected semantics that people assume for SVN usage. 20:03:03 <Greg_Noel> I think 'checkpoint' should be created, initialized with a copy of 'trunk'. Checkpoints should be prepared by, in effect, rebasing this branch from the current 'trunk'. 20:03:03 <Greg_Noel> I think 'release' (or 'production' or 'official' or 'whatthehell') should be created, initialized with a copy of the new 'checkpoint'. Official releases should be created by, in effect, rebasing this branch from the current 'checkpoint'. 20:03:03 <Greg_Noel> I think we should plan for a 1.0.1 release, with a checkpoint in two weeks and a release in three. It should contain only regressions and documentation. It's a 'bug fix' release. 20:03:03 <Greg_Noel> I think 1.0, 1.0.x, and 1.x should be triaged for the regressions and documentation to put in 1.0.1. We should work only on those issues for the next two weeks, until the checkpoint (which is effectively 1.0.1-rc1). The issues in 1.0 and 1.0.x that are not selected for 1.0.1 should be placed in 1.x (if they are not regressions) or 1.0.x and we should further plan for a 1.0.2 release another two or three weeks after 1.0.1. 20:03:03 <Greg_Noel> I think we should not create a branch for 2.0 development until the backlog is triaged and 1.x is re-triaged so we can get a better idea of how much work is entailed. 20:03:03 <Greg_Noel> Comments? All in favor? 20:03:50 <stevenknight> :-) 20:04:01 <stevenknight> your typing sure improves when you have a lot to say... :-) 20:04:02 <Greg_Noel> As you can tell, I've been practicing my typing speed... 20:04:32 <stevenknight> okay, i don't have a problem with any of this conceptually 20:05:13 <Greg_Noel> But not conceptually, the problem is? 20:05:19 <stevenknight> there are two things I need to get clear on 20:05:35 <stevenknight> one is how to actually put the transition into effect 20:06:08 <stevenknight> especially w.r.t. re-hanging existing development branches 20:06:19 <Greg_Noel> transition: just do it; it's a 1.0 thing. 20:07:02 <stevenknight> so what happens to my development work that's based off branches/core? I just have to recreate all of it by hand? 20:07:11 <stevenknight> you're a cruel man 20:07:49 <stevenknight> let me fill in some background: 20:08:09 <stevenknight> i have a lot of working copies of various things off branches/core 20:08:14 <stevenknight> in various stages of completeness 20:08:16 <Greg_Noel> Supposedly, SVN can handle that, but since all of it is not directly part of SVN, I don't know if there will be problems. 20:08:54 <stevenknight> SVN can handle an "svn switch" to point the URL to a different repository 20:09:08 <stevenknight> it can't handle the attributes that svnmerge manages to track what has or hasn't been synchronized to the branch 20:09:26 <stevenknight> (different repository or different branch on same repository) 20:09:34 <Greg_Noel> It knows the history of a branch, so it can find the missing revisions for rebasing. Just rebase to the end of branches/core, then switch to trunk 20:09:58 <Greg_Noel> at least, that's the theory 20:10:38 <stevenknight> sigh -- "theory" meeting "practice" is where I'm concerned I only have enough knowledge to cause myself a lot of trouble 20:10:46 <Greg_Noel> maybe we should raise it in the SVN mailing lists and see what they say 20:11:50 <stevenknight> or maybe i should stop whining and just educate myself... :-) 20:12:16 <Greg_Noel> worksforme {;-} 20:13:02 <stevenknight> okay, so help me walk through the broad outline of steps that'll be necessary here... 20:13:10 <Greg_Noel> go for it 20:13:12 <Pankrat1> Ok, sun is rising ... Good night to all 20:13:26 <stevenknight> Ludwig: many thanks 20:13:26 <Greg_Noel> sleep well... 20:13:41 * Pankrat1 has quit ("Leaving.") 20:13:59 <stevenknight> 1) sync all available branches/core working copies 20:14:11 <stevenknight> 2) svnmerge all available branches/core subsidiary branches 20:14:23 <Greg_Noel> Ah, no 20:14:35 <stevenknight> from branches/core down to the branches 20:14:43 <stevenknight> not sync them up 20:15:48 <Greg_Noel> No, SVN remembers history. At any time, you can move to the "tip" of branches/core and merge over any changes into developmental branches 20:16:06 <Greg_Noel> In other words, that doesn't have to be done now. 20:16:26 <Greg_Noel> (It would be good to do it now, but it's not necessary) 20:16:47 <stevenknight> okay 20:16:52 <stevenknight> (hang on, interrupt...) 20:17:11 * Greg_Noel just had food arrive, brb 20:19:30 <stevenknight> back 20:19:38 <stevenknight> okay, i can delay svnmerge 20:19:47 <stevenknight> but will probably do it anyway because I'm superstitious 20:20:06 <Greg_Noel> {;-} 20:22:07 <stevenknight> 3) sync branches/core up to trunk 20:22:21 <stevenknight> 4) "svn cp trunk branches/checkpoint" 20:22:30 <stevenknight> 5) "svn cp branches/checkpoint branches/release" 20:22:40 <Greg_Noel> yes, yes, yes 20:22:42 <stevenknight> 6) release from branches/release 20:22:48 <Greg_Noel> yes 20:24:17 <stevenknight> if packaging needs changes to work from branches/release: 20:24:28 <stevenknight> a) make them in branches/release and push back up? or 20:24:35 <stevenknight> b) make them in trunk and push down? 20:25:38 <Greg_Noel> I would imagine that there would be one file (or a piece of one file) that contains the packaging-specific information; that's why I said "rebase" rather than "sync". 20:26:04 <stevenknight> too subtle 20:26:15 <Greg_Noel> or too sneaky? 20:27:07 <Greg_Noel> It should be well-documented, probably in the pages about how to prepare a release. 20:27:29 <stevenknight> too subtle, if you expect the choice of one word to be parsed such far-reaching meaning 20:27:47 <stevenknight> agreed re: what it should look like, but I'm going to be wrestling with the current state of code 20:28:26 <Greg_Noel> It doesn't have to be perfect the first time; we can evolve to that point. 20:28:36 <Greg_Noel> It may even take a number of iterations. 20:28:41 <stevenknight> okay, so i'm trying to anticipate what that evolution will look like 20:28:50 <stevenknight> real use case: 20:29:11 <stevenknight> our packaging won't build from branches/release because of some unintended dependency on being executed from trunk 20:29:19 <stevenknight> do I fix it in branches/release and push it up 20:29:26 <stevenknight> or fix it in the trunk and push it down? 20:29:55 <Greg_Noel> not branches/release, release 20:30:05 <stevenknight> fine 20:30:11 <stevenknight> do i fix in release and push it up 20:30:16 <stevenknight> or fix it in the trunk and push it down? 20:30:46 <Greg_Noel> whatever's most convenient for the first time; it will show where the evolution should take place. 20:31:02 <stevenknight> gah 20:31:40 <stevenknight> i don't know what's convenient and I'm trying to anticipate things that (given my past patterns) i'll use as mental blocks to avoid getting the damn thing done 20:31:44 <stevenknight> a little help here 20:31:50 <Greg_Noel> Don't forget, a package made from the trunk is scons.r12345. 20:32:04 <Greg_Noel> or should be 20:33:42 <stevenknight> Greg, you're about this close to losing this chance to get a branching strategy that you want in place because you won't help me anticipate a potential problem so i won't stall myself if it occurs... 20:34:43 <Greg_Noel> I suspect the problem is that I've never prepared a release, so I don't understand what obstacles you're seeing. 20:34:53 <stevenknight> once again 20:35:14 <stevenknight> suppose I run into a problem in the SConstruct file where it won't build the package we want from the release/ branch 20:35:19 <stevenknight> because of some unintended dependency 20:35:25 <stevenknight> i have to make a change to the SConstruct file to fix it 20:35:32 <stevenknight> do I make the change in release/ and push it to trunk/ 20:35:46 <stevenknight> or do I make the change in trunk/ and push it down to release/ 20:35:51 <stevenknight> (through checkpoint/ in each case, of course) 20:36:15 <Greg_Noel> safer to go from trunk to release so it doesn't get lost, I'd imagine 20:36:24 <stevenknight> okay, i'll do that 20:37:10 <stevenknight> 7) (or whatever step we're up to) 20:37:15 <Greg_Noel> one other option would be to release 1.0 from branches/core and make this transition part of 1.0.1 20:38:17 <stevenknight> in other words, do what i've been doing so we're not changing that variable at the last minute? 20:38:25 <Greg_Noel> yes, exactly. 20:38:27 <stevenknight> works for me at the moment... 20:38:50 <Greg_Noel> It would gain you a couple of weeks to stress it 20:38:51 <stevenknight> okay, but then let's set up a specific time/TASK issue to refactor the branches 20:39:05 <stevenknight> so it doesn't keep getting delayed 20:39:06 <Greg_Noel> works 20:39:22 <stevenknight> okay, i'll go ahead and do what I've been doing for now 20:39:35 <Greg_Noel> I'll make it a task for 1.0.1 p1. 20:39:35 <stevenknight> i think it's just you and me left, yes? 20:39:45 <Greg_Noel> yes 20:40:23 <stevenknight> okay, any reason not to shoot for same time next week? 20:41:20 <Greg_Noel> works for me. if you think 1.0 will be out by then, I'll add an agenda item to retriage the incomplete 1.0 issues, as well as 1.0.x. 20:41:46 <stevenknight> yeah, i'm going to try to get it out in the next day or so 20:42:01 <stevenknight> oh, actually, the other thing i'm looking for: 20:42:12 <stevenknight> okay, don't cut a 2.0 branch, i can go with that 20:42:35 <Greg_Noel> We really need to assess what's going to be done during 1.x 20:42:49 <stevenknight> so your suggestion for where to store future to-be-integrated work is...? 20:42:57 <stevenknight> just a private branch? 20:43:14 <Greg_Noel> right now, there's two years worth of work in 1.x; nobody wants it to be that long 20:43:50 <stevenknight> agreed, but irrelevant to my question 20:43:56 <Greg_Noel> Hmmm, where indeed... 20:44:26 <Greg_Noel> I guess I've just been putting in TODOs, but I agree that we could use something more formal. 20:45:12 <stevenknight> well, now that i'm thinking about it a little more, i can see storing things in an sgk_future branch or some such 20:45:22 <Greg_Noel> (Too bad Python doesn't have #ifdefs...) 20:45:31 <stevenknight> yeah 20:45:50 <stevenknight> okay, i need to get back to my other stuff... 20:46:12 <Greg_Noel> Yeah, me too; le Tour de France is calling; we've recorded it 20:46:13 <stevenknight> later, thanks 20:46:29 <Greg_Noel> cul...