Open Source Meeting/2010-05-04

== Agenda ==
=== Agenda Tuesday, 4 May 2010 ===
# Weekly Snowglobe update - Merov Linden
# Your topic here!
If we run out of topics before the end of the meeting, we'll triage Snowglobe or Open Source specific Jira Issues from the list below.
=== Jira Issues ===
# Your issue here!
If you think an issue warrants a deeper discussion, please add it as topic to one of the agendas above.
== Transcript ==
[14:02]	:	http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda
[14:03]	:	I saw that Boroondas edited that agenda
[14:03]	:	Has it been updated? :-0
[14:03]	:	looks nice :)
[14:03]	:	well, the overall template
[14:04]	:	Now it just needs instructions on how to add an issue or jira number.
[14:04]	:	so, first order of work is my update
[14:04]	:	i wonder how many saw my patch to the way chat and IM logs are saved ?
[14:04]	:	I got svn 1.4 branch building on my systme
[14:04]	:	cool Techwolf!
[14:05]	:	im doing V2 branch
[14:05]	:	I've been working on several things on SG2.0 this past few days
[14:05]	:	first export scripts:
[14:05]	:	after i got to finaly build on my system
[14:05]	:	I still got 1.4 .. did it ever not compile?
[14:06]	:	We had broken/missing files from S3. That got fixed.
[14:06]	:	there was a problem with eol sometimes and I've been trying to fix it, unfortunately breaking the build (and hence the export) in the process
[14:06]	:	im having to build v2 on vs2005 though still working on getting it to build in vs2008 or vs 2010
[14:06]	:	I've been working on this this morning, hope it'll be fixed by EOD
[14:06]	:	You're not compiling standalone Techwolf?
[14:07]	:	Aleric, yes, standlone, but the artwork and libs disapeared off of S3.
[14:07]	:	another news on 2.0 is that we now completed the creation internally of viewer-public
[14:07]	:	so I'll be hooking the export directly to this asap
[14:07]	:	(as soon as I fix the export script...)
[14:07]	:	Will there be commint comments?
[14:07]	:	that should be pretty cool!
[14:08]	:	Techwolf: yes!
[14:08]	:	I have a patch in the script to export the comments in clear
[14:08]	:	Good. I'me sure a lot of tpv would like to cherry pick some bug fixes for backporting.
[14:08]	:	yup
[14:08]	:	The first sync though will be pretty bulky again
[14:09]	:	but that should become less of a problem once we do that automatically
[14:09]	:	Did some port VWR-12984 to 2.0, or will someone? I'm not using 2.0, but that patch should be added to all viewer, also snowglobe 2.0, and also viewer 2.0.
[14:09]	:	http://jira.secondlife.com/browse/VWR-12984 [#VWR-12984] 1.23: Water flickers and disappears in patches
[14:09]	:	so what dose any one here think of SNOW-622
[14:09]	:	http://jira.secondlife.com/browse/SNOW-622 [#SNOW-622] Adding Date Stamp to Chat and IM logs
[14:10]	:	Aleric: yes, that should be ported. If you could do it, that'd be great.
[14:10]	:	I don't know how different the code you modified is in 2.0
[14:10]	:	I don't use 2.0 ... didn't even download it yet :/
[14:11]	:	well im currently runing on a build with that in it
[14:11]	:	I alternate between the 2 all the time
[14:11]	:	Maybe Thickbrick is willing to do the port. He's co-author.
[14:11]	:	Also, I've been starting going systematically through all the 1.x commits and see what needs to be ported
[14:12]	:	merov it adds the ability to date stamp the chat and IM logs if your saving them
[14:12]	:	that's going to keep me busy for a while (few days) for sure
[14:12]	:	lets talk about that 622 from WolfPup
[14:12]	:	:)
[14:12]	:	Error
[14:13]	:	err
[14:13]	:	nm - wrong number :)
[14:14]	:	Oh, I looked at that before and I'd not like to use it. So, it should be optional :p
[14:14]	:	snow-622 is Split files by timesteamp?
[14:14]	:	Henri has the same comment
[14:14]	:	and I think it's fair
[14:14]	:	the second patch i added has a switch in advanced>debug so that you can turn it on or off
[14:15]	:	/me checks that patch
[14:15]	:	Seems rather pointless to me - except and ONLY if you want to use log rotation.
[14:15]	:	free actualy by date stamp
[14:15]	:	And I don't, I want to keep ALL logs, forever.
[14:15]	:	aleric then you do not mind having to search through megs od text to find what you need if nessary?
[14:16]	:	this would give yu the ability to look at a particular days cat logs
[14:16]	:	For log rotation, just logrotate, it has a new feature to rotate by date instead of just incrmenting a number.
[14:17]	:	I always cringe when I see date formatting being done "manually"...
[14:17]	:	we should use ICU in the viewer
[14:17]	:	Wolf: What difference does it make in that case whether you have 1000 files of 1 Meg, or 1 file of 1000 Megs? Same number of megs.
[14:17]	:	for all those dates and time formatting, leaving them locale sensitive
[14:18]	:	actualy the dat stamp seems to be working off of UTC and not local
[14:18]	:	So far I had no problems finding anything back. I surely can't remember the date on which something was said - at most I can remember who said it, or that it was in local chat.
[14:18]	:	locale sensitive might not always be the best choice
[14:18]	:	The date/time sytem with the SL codebase is severlly borken.
[14:18]	:	Techwolf: +1
[14:19]	:	that was a general comment indeed
[14:19]	:	it is getting utc time
[14:19]	:	WolfPup: Obviously, I search not with my eyes :p ... I use 'grep'. And I have time stamps in the logs, so if I know a date range then I add that to the regular expression.
[14:20]	:	Another concern: Chat and IM windows use to show a short backlog of previous conversations. I guess they take that from the logs. If the last conversation would be from a previous day/month that'd fail, wouldn't it?
[14:20]	:	There needs to be a project in witch that goes through the codebase and convert everything to UTC
[14:20]	:	aleric to you host regular daily events?
[14:20]	:	with lots going on in local caht?
[14:21]	:	well, OK with me to have this extra printout as an option
[14:21]	:	we need some more code review though
[14:21]	:	Someone to take the lead on that one?
[14:21]	:	/me realizes that only Aleric and him are committers here...
[14:22]	:	btw, MichelleZ is en route now.
[14:22]	:	good :)
[14:22]	:	Its a usfull obsure featrue for some folks. Keep at it wolfpup and imporov it to account for international settings and keep it a default off debug setting. Not many would use it.
[14:22]	:	i did try to use the same date/time system that it down in the timestamp setion of lllogchat but it kept failing to compile or would not give the right output to the filename till i hard coded it
[14:23]	:	K, I'm going to set "Fix version" to "2.0" so we pick it up and it shows up on the committers' radar
[14:24]	:	wolfpup, you may have to add antoher debug setting to use UTC or local time and figure out a way to pick up the date/time stamp format of the local user.
[14:24]	:	I don't mind when it's implemented as optional of course, but I'd be upset if it ever was (suddenly) turned on, alpha/beta or debug. It would screw up my logging. It should be off by default and at any point in the commits.
[14:24]	:	when i was first trying to get it working i would get this --- chat-year,datetime,slt-mthnum,datetime,slt-day,datetime,slt as the output filename
[14:25]	:	literally? or are those placeholders?
[14:25]	:	even though the patch that includes the debug setting it defaulted to on it could be set to be defaulted to off
[14:25]	:	/me edited the JIRA
[14:26]	:	that is exactly the file name i would get when i first tried
[14:26]	:	Just use some new persisting debug setting that is off by default
[14:26]	:	ok, one thing I wanted to review is the list of patches assigned to 1.4
[14:26]	:	the is what the debug setting is for
[14:27]	:	it is just when i made the patch file i ad it defaulted to on
[14:27]	:	wolfpup, rework the patch to default off and put all the intro comments at the top of the patch where they can be ignored by the patch program. No need to have all those comments in the code. Just a one liner explaing the debug setting/feature is enought.
[14:27]	:	WolfPup, yes but
[14:27]	:	+ <key>Value</key> + <integer>1</integer>
[14:27]	:	should be <integer>0</integer>
[14:28]	:	[17:25] <MichelleZ> ping t_brick or Techwolf if either of you are inworld at the meeting i can't log in for various silly reasons ;-/
[14:28]	:	Also move the '//static' to where it belongs
[14:29]	:	ok ill make a new patch file and up load it
[14:29]	:	:-)
[14:29]	:	/me agrees with Aleric's quick review
[14:29]	:	actualy that static was already there
[14:29]	:	i just add the coments to it is all
[14:30]	:	k, we'll check your patch WolfPup :)
[14:31]	:	I'd like to review some 1.4 pending patches
[14:31]	:	There are more style things... like the declaration of all new local variables should be inside the scope of the new if().
[14:31]	:	ok ill let you know as soon ad i upload a new patch with the defaut as off
[14:31]	:	first would be: SNOW-440
[14:31]	:	http://jira.secondlife.com/browse/SNOW-440 [#SNOW-440] Media plugins have no way to log errors.
[14:33]	:	/me checks "Hmm...I have three patches waiting, one of them is for 1.4."
[14:33]	:	on SNOW-440, I think Thickbrick should go ahead and commit
[14:34]	:	that's one we should take in SG2.0 BTW, debugging plugins is hit and miss without some trace
[14:34]	:	+1 on commiting that patch. I get media errors sometime and nothing on the console.
[14:34]	:	Techwolf: please, go ahead with your patches
[14:35]	:	type the JIRA here and we'll go through them
[14:35]	:	I read 440, and I think it won't help much... at least not in the cases of core dumps.
[14:35]	:	So, then you got to ask yourself if there isn't a better way.
[14:35]	:	/me picks the most usfull one first....
[14:35]	:	http://jira.secondlife.com/browse/SNOW-630
[14:35]	:	[#SNOW-630] Finished port of SNOW-307
[14:36]	:	Aleric: true, but too often, the only info we have from plugin issues is "won't work!", no crash, no trace, nothing...
[14:36]	:	Right now, the 2.0 code base is using the same mine_type file for all three OSes.
[14:36]	:	nothing in the log in particular
[14:36]	:	/me waits.
[14:37]	:	in doc/contributions.txt, also add snow-307, so we know it's been ported
[14:37]	:	http://jira.secondlife.com/browse/SNOW-307 [#SNOW-307] Linux viewer builds renames gstreamer plugin to quicktime.
[14:37]	:	ok new patch with default set to off added
[14:37]	:	ah right
[14:37]	:	this was so fuggly...
[14:38]	:	Ok, it would help if you get that info from users. For developers, I think it should be fully supported and possible to run the SLPlugin in a debugger as the only right way to debug it. And THAT has a problem, since right now any normal output to stdout (I think that this is the reason anyway) totally confuses the communication between parent process and the plugin with as the normal result "nothing" and "it doesn't work".
[14:38]	:	What we need is that the pipes between the parent and SLPlugin doesn't use file descriptors 0, 1 or 2 anymore. But use 3 and 4 for example
[14:40]	:	You're certainly right Aleric
[14:40]	:	Debugging plugins is an issue that needs a solution
[14:40]	:	We should get Monroe involves in such a discussion as he's the keeper of that code
[14:41]	:	I wonder what they use to debug their plugins...
[14:41]	:	on my system i can not build the to have debug available
[14:42]	:	changing this though should be done asap, before we have too much of a legacy of existing plugins
[14:42]	:	especially 3rd party plugins
[14:42]	:	had to set VS2005 to Release only not even Releasewith Debug
[14:43]	:	Boroondas, re:snow-307, where sould that be place in contrub doc? I notice a Linden did the patch for it.
[14:43]	:	Stange WolfPup
[14:43]	:	which Windows OS flavor do you run?
[14:43]	:	oh
[14:44]	:	um ... then we need a better mechanism to track what ports are in SVN
[14:45]	:	re:snow-307. I think I put it under me as I was the ornigle bug reporter.
[14:45]	:	there's no problem having Linden contributing patches... they just don't get the credit in the contrib doc
[14:45]	:	but you'll get the redit for 630 Techwolf :)
[14:46]	:	yeah, but for patches ported over from 1.x to 2.x, we used to add both issue numbers, so that a diff could show what still needs porting
[14:46]	:	if the original isn't in contributions.txt, because it's a linden patch, that approach won't work
[14:46]	:	yes... hmm...
[14:46]	:	Boroondas, I've did that in http://jira.secondlife.com/browse/SNOW-617
[14:46]	:	[#SNOW-617] Missing contributions.txt additions.
[14:47]	:	well, we can't go back to add those
[14:47]	:	windows 7 32-bit
[14:48]	:	Still Boroondas, how having the original bug in contrib helps? we're not changing things for those are we?
[14:49]	:	for instance: 630 being done would change something on 307 line?
[14:49]	:	(assuming it was there)
[14:49]	:	Merov, snow-307 was comminted with no doc entry.
[14:49]	:	how do you see the association 630/307 in the diff?
[14:50]	:	nope. lines present in the 1.x contribution.txt but missing from the 2.x contributions.txt would indicate issues that still need porting
[14:51]	:	oooo... you would take 307 out then
[14:51]	:	right?
[14:51]	:	hu?
[14:51]	:	snow-307 is missing from the 1.x txt. I just happen to noticed it got borke in the 2.0 codebase.
[14:52]	:	I know Techwolf, I'm trying to understand that tracking port idea and I don't think it works
[14:52]	:	let's *assume* for a sec that 307 was there (contributed by Aimee for instance)
[14:53]	:	under the proposed tracking, we would take that attribution out (so it shows as "missing") when committing the 630 port
[14:53]	:	no
[14:54]	:	ok, then I didn't understand
[14:54]	:	in branches forked before it was commited it would already be missing
[14:54]	:	in branches forked afterwards, the entry AND the patch would be present
[14:54]	:	when you port it to a branch where it was missing, you should also add the "old" number, so it doesn't show as missing anymore
[14:55]	:	Its just snow-307 got commneted with entry, so the diff would not show it. But for everything else, the diff works for checking the ports.
[14:55]	:	That is untill everything got ported over then this would be a non-issues at that point.
[14:55]	:	indeed
[14:56]	:	but, we have everything in the current 2.0 contrib.doc, including ref to patches that need to be ported
[14:56]	:	Boroondas is trying to throw a monkey wrench into the works. :-)
[14:57]	:	I don't even follow the problem :)
[14:58]	:	The problem is snow-307 is missing from contrube.txt and broondas wants it added somewhere.
[14:58]	:	Just commit it
[14:58]	:	yeah
[14:58]	:	+1 Aleric
[14:59]	:	I don't want to add it anywhere, I just noticed our previous approach didn't work.
[14:59]	:	who decided on this approach?
[14:59]	:	We wasted enought time and there is two more patches.
[14:59]	:	I'm not even aware of it...
[15:00]	:	If the problem is "how to track if a patch that was committed to SNOW went into the internal branch" ... then I hope that works automatically now, ... we are using a repository for that no? *confused*
[15:00]	:	IIRC I suggested it some time ago and you (Merov) approved it.
[15:00]	:	/me as confused as Aleric...
[15:00]	:	/me is taking a self timeout, afk
[15:00]	:	But I don't think there was any formal decision on it
[15:00]	:	no, I approved that people contributing ports would log a JIRA and get credit for a port
[15:01]	:	anyway, back to JIRAs
[15:01]	:	What I am "afraid" of is that when an internal dev ports a snowglobe patch to the internal repro, that they'd do that manually - changing bits - perhaps forgetting the contributions.txt hunk etc - such that all relationship between the two vanish.
[15:01]	:	I may have misunderstood the original discussion but I never though it'd be used as a port tracking mechanism
[15:02]	:	In the case of 'git' and a prefect copy of the patch, it would just note that it was already applied to SG when merging it back and there would be no problems. But that only works if the internal devs take out patches literally - and only then maybe add changes on top of it in a new commit
[15:02]	:	take our*
[15:03]	:	ok, before we review the 2 other patches from Techwolf, lets agree to move that tracking port discussion to opensource-dev
[15:03]	:	ok
[15:04]	:	it's a good idea, I'm just not convinced the solution proposed works (and I'm unclear on what the solution is)
[15:04]	:	/me edits 630
[15:04]	:	One for 1.4 codebase, http://jira.secondlife.com/browse/SNOW-497
[15:04]	:	[#SNOW-497] Add option to run unit tests for STANDALONE
[15:04]	:	/me plans on stealing Latha's stuffed animal toy.
[15:05]	:	/me chuckles as he was allready plotting ongetting that toy...
[15:07]	:	No commnets, patch must be that good. ;)
[15:07]	:	497 is good, what about porting it to 2.0 too?
[15:07]	:	dunno if that's related, but I think I still can't build with LL_TESTS set to ON
[15:07]	:	No port needed.
[15:07]	:	LL_TESTS is in 2.0 codebase.
[15:07]	:	kk
[15:07]	:	ah, right
[15:08]	:	I created that patch before 2.0 was dropped and then updated it after 2.0 was dropped to use open source folks.
[15:08]	:	use=us
[15:08]	:	k, edited the JIRA
[15:08]	:	next and last from you Techwolf?
[15:09]	:	An easy one. http://jira.secondlife.com/browse/SNOW-617
[15:09]	:	[#SNOW-617] Missing contributions.txt additions.
[15:09]	:	ah right, yes, go for it!
[15:09]	:	I"me not a commiter. :-(
[15:10]	:	ooops... k, I'll take it...
[15:10]	:	/me thinks we should consider making Techwolf a committer
[15:10]	:	What is your largest patch TechWolf?
[15:10]	:	let me look how it looks :)
[15:11]	:	/me thinks
[15:11]	:	merov i have added an updated patch to SNOW-622 with default set to off
[15:11]	:	http://jira.secondlife.com/browse/SNOW-622 [#SNOW-622] Adding Date Stamp to Chat and IM logs
[15:11]	:	Thanks WolfPup!
[15:12]	:	please bring the issue to opensource dev so that others (not present here) have a chance to review
[15:12]	:	ok
[15:12]	:	thanks!
[15:12]	:	ok, 3:12 already!
[15:12]	:	WolfPup, some of the mentioned issues, remain: //static belongs after the new comment. The initializations belong into the if scope, credits don't belong into the in-code comment
[15:13]	:	I just did a jira search. None of them stand out a large ones except if you count all the gcc warning fixes as one.
[15:13]	:	need to check that build before I leave so I need to go now :)
[15:13]	:	see you Thursday
[15:13]	:	cu
[15:13]	:	bye
[15:14]	:	I am planning on making a large one for WVR to fix all the linux packaging issues that have been commited to snowglobe 2.0 so they can import it internially.
[15:14]	:	well, that'll just be a rediff of a series of existing patches, right?
[15:16]	:	yes, plus one fix for the viewer-internail code base. They left out a chunk in the viewer_manifest.py.
[15:16]	:	WolfPup: writing patches works as follows: you put heaps of blood sweat and free time into something, then you only get negative feedback; If that puts you off and you give up because "it won't be accepted anyway", then it won't ever be accepted. However, that feeling is not how you should feel. The correct feeling is to try and take EVERY comment and fix it to satisfy it (or discuss it first if you really disagree). Then come with a patch that addresses each and every comment - perhaps you get again comments, if so, you do it again. That way the patch will reach a point were suddenly people will say: ok, commit that. That's how it works ;)
[15:17]	:	Aleric, the biggest one that I can find right off paw is http://jira.secondlife.com/secure/attachment/36421/SNOW-517_viewer_manifest_v2.patch
[15:17]	:	http://jira.secondlife.com/browse/SNOW-517 [#SNOW-517] viewer manifest is incomplete on 64bit
[15:17]	:	The worst thing that can happen (happened to me) if when people have no time to review it: so you get no comments, but also no commit :/
[15:17]	:	As long as you get comments, you have progress.
[15:18]	:	/me sings: Always look at the bright side ... of patchs! Di-dumm, di-dumm-di-dumm-di-dumm!
[15:18]	:	techwolf: that isn't even C++ ... I can't judge based on that if you'd be a good committer :/
[15:19]	:	Social life calls... cya next week I guess.
[15:19]	:	/me shrugs "Sorry."
[15:20]	:	I think more important for a commiter than whether he/she writes good code, is whether they can judge others' code
[15:20]	:	Certainly for a reviewer - which are very important (shortage).
[15:21]	:	(those two might correlate, of course)
[15:21]	:	But reviewing is harder than writing a patch yourself imho
[15:21]	:	indeed
[15:21]	:	I'd be a very bad reviewer I'm afraid :/
[15:22]	:	My TP arrived
[15:22]	:	bye!
[15:22]	:	and your code is kinda hard to review
[15:22]	:	see you
[15:22]	:	bye
 
Generated with SLog Wikifier