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...