1 19:01:54 <Greg_Noel> Anybody here for the bug party?
2 19:02:16 <Pankrat1> Yes, me (Ludwig)
3 19:02:27 <Pankrat1> Good Morning Greg :)
4 19:03:03 <Greg_Noel> Yeah, I'll bet it's a ghastly hour of the morning; aren't you UTC+1?
5 19:03:39 <Pankrat1> UTC+2 actually (Daylight saving time)
6 19:04:04 <Greg_Noel> Sommerzeit...
7 19:04:19 <Pankrat1> Ja ... but I'm used to work late in the evening if day-work permits
8 19:05:00 <Greg_Noel> Well, I'm not seeing anyone else...
9 19:05:30 <Greg_Noel> No Steven, no Bill, no Jim, no Ken (Gary is on holiday)
10 19:07:38 <bdbaddog> Good day all.
11 19:07:53 <Greg_Noel> Welcome.
12 19:08:14 <Pankrat1> Hello Bill
13 19:08:23 <Greg_Noel> How long can you stay tonight?
14 19:09:14 <bdbaddog> probly 10-20 minutes. :(
15 19:10:03 <bdbaddog> not that many bugs on the current issues list.
16 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.
17 19:10:04 <Pankrat1> Bill: Interesting idea concerning the chunk MD5 shortcut.
18 19:10:21 <Pankrat1> but it's not done (yet)
19 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.
20 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
21 19:12:14 <bdbaddog> users could tune to nfs rsize...
22 19:12:33 <Greg_Noel> 64Kb == large. My first UNIX system had 98Kb...
23 19:12:43 <bdbaddog> My first home system had 8kb.
24 19:12:52 <bdbaddog> now my phone has 2GB.
25 19:12:53 <Greg_Noel> Was it multi-user?
26 19:13:03 <bdbaddog> nope. commodore pet.
27 19:13:24 <Greg_Noel> Nice machine; I still have a bunch of Amigas.
28 19:13:25 <bdbaddog> we had a pdp 11/70 timeshare in highschool.
29 19:13:40 <bdbaddog> I have an atari 800 in the garage.
30 19:14:18 <bdbaddog> I'll ping Steven on another IM system.
31 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.
32 19:18:52 <Pankrat1> Greg: In the spreadsheet (1646) you mentioned some issues you wondered about?
33 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.
34 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.
35 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."
36 19:37:39 * stevenknight (n=stevenkn@nat/google/x-561066767c2a9eb6) has joined #scons
37 19:37:45 <stevenknight> hey there -- anyone still here?
38 19:37:51 <Greg_Noel> No, not a soul.
39 19:38:09 <stevenknight> sorry for the delay, unanticipated emergency...
40 19:38:23 <Greg_Noel> We were beginning to worry...
41 19:38:41 <stevenknight> nothing life-threatening, just work...
42 19:38:51 <Greg_Noel> Bill is off pinging you elsewhere and Ludwig has probably fallen asleep.
43 19:39:03 <bdbaddog> :) nah I'm here.
44 19:39:13 <Pankrat1> Still there :)
45 19:39:38 <Greg_Noel> OK, I think this is good enough for a quorum; shall we proceed?
46 19:39:58 <stevenknight> ready when everyone else is
47 19:40:13 <stevenknight> 1646, then?
48 19:40:16 <Greg_Noel> issue 1646
49 19:40:45 <stevenknight> good point by Greg re: lack of regression
50 19:40:50 <Greg_Noel> It's an enhancement, so it can't be 1.0.x, but anything soon after that is good.
51 19:40:53 <stevenknight> i can go with 1.x p2
52 19:40:57 <Greg_Noel> done
53 19:41:02 <stevenknight> 2147:
54 19:41:08 <Greg_Noel> Ludwig, you OK with that?
55 19:41:25 <Pankrat1> 1.x is good. Patch review would be good.
56 19:41:35 <stevenknight> pankrat++
57 19:41:45 <bdbaddog> +1
58 19:41:51 <Greg_Noel> Steven for the code review; I don't know the code.
59 19:41:58 <stevenknight> 2147: i didn't realize this required batch builders
60 19:42:04 <stevenknight> (shows how closely *I* looked...)
61 19:42:26 <Greg_Noel> Yes, the vala builder is even discussed in 1086
62 19:42:58 <stevenknight> yeah, 1.x p4 feels right to me
63 19:43:03 <Greg_Noel> All the sources must be in the command.
64 19:43:05 <Greg_Noel> done
65 19:43:10 <stevenknight> 2148:
66 19:43:48 <stevenknight> hmm, i can go with 1.x p1
67 19:43:50 <Greg_Noel> Somebody needs to troubleshoot with him and get a test case. Bill?
68 19:43:56 <stevenknight> if only because 1.0.x is already getting pretty full
69 19:44:07 <Greg_Noel> More than full, overflowing.
70 19:44:41 <bdbaddog> I don't even know what the heck vala is?
71 19:44:41 <bdbaddog> :)
72 19:44:51 <stevenknight> not vala, we're on 2148
73 19:44:54 <bdbaddog> yes. we'll ahve to retriage them at somepoint.
74 19:45:06 <stevenknight> the MSVS_USE_MFC_DIRS thing
75 19:45:23 <bdbaddog> sure sign me up. I'll trade some emails and get some way to test this problem.
76 19:45:29 <Greg_Noel> done
77 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
78 19:45:40 <stevenknight> 2149:
79 19:46:01 <stevenknight> agree again w/Greg's not-a-regression criteria
80 19:46:07 <stevenknight> 1.x p1
81 19:46:10 <Greg_Noel> done
82 19:46:10 <Pankrat1> 2149: low profit, low risk 1.x low priority
83 19:46:29 <stevenknight> but a big win for low risk, so high priority... :-)
84 19:46:39 <Pankrat1> ok :)
85 19:46:49 <stevenknight> want to make sure it doesn't get shoved off the end of the list by mistake
86 19:47:07 <Greg_Noel> And a patch gets priority
87 19:47:27 <stevenknight> 2150: agree that it's not the same fix
88 19:47:36 <stevenknight> but the problem being described is (i believe) a dup of 1957
89 19:47:40 <Greg_Noel> better testing++
90 19:47:45 <stevenknight> and benoit's fix in 1957 should take care of it
91 19:47:57 <stevenknight> mind you, that's without *any* real triage...
92 19:48:16 <Pankrat1> 2150: looks like a simple race condition to me ??
93 19:48:38 <stevenknight> probably
94 19:48:54 <Greg_Noel> but 1957 is something worse, an error due to the race
95 19:49:37 <Greg_Noel> How about Ludwig to look at 1957 and see if they're the same?
96 19:49:49 <stevenknight> sounds good to me, research Ludwig
97 19:49:54 <Greg_Noel> done
98 19:50:01 <Pankrat1> ok
99 19:50:36 <stevenknight> 2151: i think Greg's right, anytime p4
100 19:50:37 <Greg_Noel> 2151, anytime p4
101 19:50:43 <Greg_Noel> done
102 19:50:52 <stevenknight> where "anytime" might include 1.0.x, of course... :-)
103 19:50:59 <Greg_Noel> yes
104 19:51:04 <stevenknight> 2152:
105 19:51:27 <stevenknight> i can go either way
106 19:51:46 <Greg_Noel> I'd prefer 1.x
107 19:51:50 <Greg_Noel> p2
108 19:52:05 <bdbaddog> 1.x
109 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
110 19:52:40 <Greg_Noel> True, but if Mati decides to fix it during 1.0.x, that's fine.
111 19:52:43 <stevenknight> it'd be one less to have to re-triage for 1.x
112 19:53:00 <Greg_Noel> (one fewer)
113 19:53:02 <stevenknight> okay, i can go with that
114 19:53:05 <bdbaddog> k that's fine by me.
115 19:53:11 <stevenknight> (true, one fewer)
116 19:53:23 <Greg_Noel> 1.x p2, then
117 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?
118 19:54:46 <Greg_Noel> Send a message to dev saying it's ready; if consensus, then apply.
119 19:54:54 <bdbaddog> sounds good.
120 19:54:54 <stevenknight> works for me
121 19:54:59 <stevenknight> 2153:
122 19:55:20 <Greg_Noel> Needs a patch, or a better test case
123 19:55:21 <stevenknight> not a functional regression, but i think it's a pretty serious hidden defect
124 19:55:44 <stevenknight> good point re: not really knowing the scope of this
125 19:55:59 <stevenknight> hard to say it definitely *must* go into 1.0.x unless we can gauge the potential impact
126 19:56:07 <stevenknight> research?
127 19:56:15 <Greg_Noel> hmmm, ok, who?
128 19:56:17 <bdbaddog> yup.
129 19:56:17 <stevenknight> me
130 19:56:27 <stevenknight> 2153: research, stevenknight
131 19:56:34 <Greg_Noel> done, although you've got too many of those now
132 19:56:40 <bdbaddog> yeah. I could take that one.
133 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.
134 19:57:16 <stevenknight> but hey, I actually closed a few after last week!
135 19:57:27 <stevenknight> :-)
136 19:57:53 <stevenknight> (or researched and reprioritized, actually)
137 19:58:04 <stevenknight> don't i get a biscuit for good behavior?
138 19:58:04 <Greg_Noel> bdbaddog, how are you doing on your current research workload? Don't you still have a few?
139 19:58:11 <stevenknight> :-)
140 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.
141 19:59:46 <Greg_Noel> OK, 2153, research, Bill?
142 20:00:35 <stevenknight> works for me
143 20:00:55 <Greg_Noel> done
144 20:01:00 <stevenknight> 2154:
145 20:01:16 <stevenknight> any objections to my unilateral prioritization?
146 20:01:30 <Greg_Noel> not me
147 20:01:50 <bdbaddog> k folks I'm a pumpkin, gotta run.
148 20:01:57 <stevenknight> later bill -- thanks
149 20:02:20 <Greg_Noel> On to 1.0 strategy?
150 20:02:56 <stevenknight> yep
151 20:03:03 <Greg_Noel> I've said this before, but to recap:
152 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.
153 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'.
154 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'.
155 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.
156 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.
157 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.
158 20:03:03 <Greg_Noel> Comments? All in favor?
159 20:03:50 <stevenknight> :-)
160 20:04:01 <stevenknight> your typing sure improves when you have a lot to say... :-)
161 20:04:02 <Greg_Noel> As you can tell, I've been practicing my typing speed...
162 20:04:32 <stevenknight> okay, i don't have a problem with any of this conceptually
163 20:05:13 <Greg_Noel> But not conceptually, the problem is?
164 20:05:19 <stevenknight> there are two things I need to get clear on
165 20:05:35 <stevenknight> one is how to actually put the transition into effect
166 20:06:08 <stevenknight> especially w.r.t. re-hanging existing development branches
167 20:06:19 <Greg_Noel> transition: just do it; it's a 1.0 thing.
168 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?
169 20:07:11 <stevenknight> you're a cruel man
170 20:07:49 <stevenknight> let me fill in some background:
171 20:08:09 <stevenknight> i have a lot of working copies of various things off branches/core
172 20:08:14 <stevenknight> in various stages of completeness
173 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.
174 20:08:54 <stevenknight> SVN can handle an "svn switch" to point the URL to a different repository
175 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
176 20:09:26 <stevenknight> (different repository or different branch on same repository)
177 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
178 20:09:58 <Greg_Noel> at least, that's the theory
179 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
180 20:10:46 <Greg_Noel> maybe we should raise it in the SVN mailing lists and see what they say
181 20:11:50 <stevenknight> or maybe i should stop whining and just educate myself... :-)
182 20:12:16 <Greg_Noel> worksforme {;-}
183 20:13:02 <stevenknight> okay, so help me walk through the broad outline of steps that'll be necessary here...
184 20:13:10 <Greg_Noel> go for it
185 20:13:12 <Pankrat1> Ok, sun is rising ... Good night to all
186 20:13:26 <stevenknight> Ludwig: many thanks
187 20:13:26 <Greg_Noel> sleep well...
188 20:13:41 * Pankrat1 has quit ("Leaving.")
189 20:13:59 <stevenknight> 1) sync all available branches/core working copies
190 20:14:11 <stevenknight> 2) svnmerge all available branches/core subsidiary branches
191 20:14:23 <Greg_Noel> Ah, no
192 20:14:35 <stevenknight> from branches/core down to the branches
193 20:14:43 <stevenknight> not sync them up
194 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
195 20:16:06 <Greg_Noel> In other words, that doesn't have to be done now.
196 20:16:26 <Greg_Noel> (It would be good to do it now, but it's not necessary)
197 20:16:47 <stevenknight> okay
198 20:16:52 <stevenknight> (hang on, interrupt...)
199 20:17:11 * Greg_Noel just had food arrive, brb
200 20:19:30 <stevenknight> back
201 20:19:38 <stevenknight> okay, i can delay svnmerge
202 20:19:47 <stevenknight> but will probably do it anyway because I'm superstitious
203 20:20:06 <Greg_Noel> {;-}
204 20:22:07 <stevenknight> 3) sync branches/core up to trunk
205 20:22:21 <stevenknight> 4) "svn cp trunk branches/checkpoint"
206 20:22:30 <stevenknight> 5) "svn cp branches/checkpoint branches/release"
207 20:22:40 <Greg_Noel> yes, yes, yes
208 20:22:42 <stevenknight> 6) release from branches/release
209 20:22:48 <Greg_Noel> yes
210 20:24:17 <stevenknight> if packaging needs changes to work from branches/release:
211 20:24:28 <stevenknight> a) make them in branches/release and push back up? or
212 20:24:35 <stevenknight> b) make them in trunk and push down?
213 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".
214 20:26:04 <stevenknight> too subtle
215 20:26:15 <Greg_Noel> or too sneaky?
216 20:27:07 <Greg_Noel> It should be well-documented, probably in the pages about how to prepare a release.
217 20:27:29 <stevenknight> too subtle, if you expect the choice of one word to be parsed such far-reaching meaning
218 20:27:47 <stevenknight> agreed re: what it *should* look like, but I'm going to be wrestling with the current state of code
219 20:28:26 <Greg_Noel> It doesn't have to be perfect the first time; we can evolve to that point.
220 20:28:36 <Greg_Noel> It may even take a number of iterations.
221 20:28:41 <stevenknight> okay, so i'm trying to anticipate what that evolution will look like
222 20:28:50 <stevenknight> real use case:
223 20:29:11 <stevenknight> our packaging won't build from branches/release because of some unintended dependency on being executed from trunk
224 20:29:19 <stevenknight> do I fix it in branches/release and push it up
225 20:29:26 <stevenknight> or fix it in the trunk and push it down?
226 20:29:55 <Greg_Noel> not branches/release, release
227 20:30:05 <stevenknight> fine
228 20:30:11 <stevenknight> do i fix in release and push it up
229 20:30:16 <stevenknight> or fix it in the trunk and push it down?
230 20:30:46 <Greg_Noel> whatever's most convenient for the first time; it will show where the evolution should take place.
231 20:31:02 <stevenknight> gah
232 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
233 20:31:44 <stevenknight> a little help here
234 20:31:50 <Greg_Noel> Don't forget, a package made from the trunk is scons.r12345.
235 20:32:04 <Greg_Noel> or should be
236 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...
237 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.
238 20:34:53 <stevenknight> once again
239 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
240 20:35:19 <stevenknight> because of some unintended dependency
241 20:35:25 <stevenknight> i have to make a change to the SConstruct file to fix it
242 20:35:32 <stevenknight> do I make the change in release/ and push it to trunk/
243 20:35:46 <stevenknight> or do I make the change in trunk/ and push it down to release/
244 20:35:51 <stevenknight> (through checkpoint/ in each case, of course)
245 20:36:15 <Greg_Noel> safer to go from trunk to release so it doesn't get lost, I'd imagine
246 20:36:24 <stevenknight> okay, i'll do that
247 20:37:10 <stevenknight> 7) (or whatever step we're up to)
248 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
249 20:38:17 <stevenknight> in other words, do what i've been doing so we're not changing that variable at the last minute?
250 20:38:25 <Greg_Noel> yes, exactly.
251 20:38:27 <stevenknight> works for me at the moment...
252 20:38:50 <Greg_Noel> It would gain you a couple of weeks to stress it
253 20:38:51 <stevenknight> okay, but then let's set up a specific time/TASK issue to refactor the branches
254 20:39:05 <stevenknight> so it doesn't keep getting delayed
255 20:39:06 <Greg_Noel> works
256 20:39:22 <stevenknight> okay, i'll go ahead and do what I've been doing for now
257 20:39:35 <Greg_Noel> I'll make it a task for 1.0.1 p1.
258 20:39:35 <stevenknight> i think it's just you and me left, yes?
259 20:39:45 <Greg_Noel> yes
260 20:40:23 <stevenknight> okay, any reason not to shoot for same time next week?
261 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.
262 20:41:46 <stevenknight> yeah, i'm going to try to get it out in the next day or so
263 20:42:01 <stevenknight> oh, actually, the other thing i'm looking for:
264 20:42:12 <stevenknight> okay, don't cut a 2.0 branch, i can go with that
265 20:42:35 <Greg_Noel> We really need to assess what's going to be done during 1.x
266 20:42:49 <stevenknight> so your suggestion for where to store future to-be-integrated work is...?
267 20:42:57 <stevenknight> just a private branch?
268 20:43:14 <Greg_Noel> right now, there's two years worth of work in 1.x; nobody wants it to be that long
269 20:43:50 <stevenknight> agreed, but irrelevant to my question
270 20:43:56 <Greg_Noel> Hmmm, where indeed...
271 20:44:26 <Greg_Noel> I guess I've just been putting in TODOs, but I agree that we could use something more formal.
272 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
273 20:45:22 <Greg_Noel> (Too bad Python doesn't have #ifdefs...)
274 20:45:31 <stevenknight> yeah
275 20:45:50 <stevenknight> okay, i need to get back to my other stuff...
276 20:46:12 <Greg_Noel> Yeah, me too; le Tour de France is calling; we've recorded it
277 20:46:13 <stevenknight> later, thanks
278 20:46:29 <Greg_Noel> cul...
