Please note:The SCons wiki is in read-only mode due to ongoing spam/DoS issues. Also, new account creation is currently disabled. We are looking into alternative wiki hosts.
   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...

BugParty/IrcLog2008-07-28 (last edited 2008-07-29 11:32:18 by ip68-7-77-81)