Open Source Meeting/2010-05-18

== Agenda Tuesday, 18 May 2010 ==
# Weekly Snowglobe update - Merov Linden
## See the SG 1.x to 2.0 spreadsheet
## Roll back to 2.0.1: yes? no?
## Major features port tasks: to 
## lltexturefetch.cpp: lots of Aleric's patches half way there in 2.0 and can't be safely ported due to other changes. Should we start an audit of that code with stability and perf in mind?
# Left over topics from Thursday, May 13 (feel free to move to next Thursday):
## Question: What on earth, or in Second Life, is the 'feature' I am killing in good for?
## Regular posting of snowglobe usage stats. Will this help guide the direction of development?
# Can there be a way for folks to donate $L to non LL paid developers that work on snowglobe?
# llrobla V2.0/replacment update
# Progress on SL7B snowglobe display?
=== Jira Issues ===
# Looks like r3349 will be reverted. Do these still need discussion (e.g. for viewer-external)?:
## Changeset 3349 added unit test to llplugin but forgot LL_TESTS, resulting in a build failure in lltut.cpp
## Tries to build pulseaudio when pulseaudio not found.
## Standalone build failure r3349, cmake error on SLPlugin
## Bulding of integration_tests when not needed
## Notifier Issue Since [sldev-commits] r3349
# Unscheduled SNOW issues triage: would be good to go with the community through those and decide for some what we should take immediately (2.0 or 1.4) or later.
== Transcript ==
[13:58]	:	hi Ardy
[13:59]	:	Hi
[13:59]	:	hi Celierra
[13:59]	:	Hey Ardy, and Boroondas :)
[13:59]	:	Hi
[14:00]	:	What's been going on lately?
[14:01]	:	Yay you made it
[14:01]	:	make it
[14:01]	:	let's see ... the viewer-external merge will be rolled back, I think (maybe a topic today)
[14:01]	:	other than that, dunno
[14:01]	:	Mm, did you see the e-mail just sent by Oz introducing himself?
[14:01]	:	Lucky I got here, i'me doing a compile now for you Robin. gcc 4.4.3 for debuggin.
[14:01]	:	well, I don't know what happened the 1st time
[14:02]	:	Oz?
[14:02]	:	oh, yeah
[14:03]	:	ok, I see that the great Oz is making my agenda easier :)
[14:03]	:	this just in: https://lists.secondlife.com/pipermail/opensource-dev/2010-May/002168.html
[14:03]	:	Other than that: https://wiki.secondlife.com/wiki/Open_Source_Meeting
[14:04]	:	k, I think we should start
[14:04]	 	sees many "yellow prim road" jokes in her future
[14:04]	:	?
[14:05]	:	OK, first on the agenda, a small list of SG2.0 actions
[14:05]	:	Huh, that's inspired Aimee
[14:05]	:	so I made that darn spreadsheet public
[14:05]	:	that was a piece of work! I went through every single commit and checked the code...
[14:05]	:	glad it's done
[14:06]	:	Merov, how long did you take you to whip up that google cod?
[14:06]	:	doc
[14:06]	:	basically, the other items on the agenda derive from it
[14:06]	:	Techwolf: I didn't count, couple of days but spread out over a week I'd say
[14:07]	:	anyway, it needed to be done
[14:07]	:	so first, the proposed roll back
[14:07]	:	Wow....i'me having trouble keeping trakc of my own bugs and you did that...."we are not worthy" *bows*
[14:07]	:	I emailed the list on this as we discussed at the last Hippo meeting (Thursday)
[14:07]	:	:-)
[14:08]	:	the consensus in the meeting was : yeah, lets roll back so we work on stable 2.0.1 for a while
[14:08]	:	I am not having build issues so will just sit this topic out.
[14:08]	:	now, the 2 feedback email on the list were more nuanced
[14:09]	:	so I'm asking the question again to you guys
[14:09]	:	i've also got SNOW-659 on latest SG2 trunk
[14:09]	:	http://jira.secondlife.com/browse/SNOW-659 [#SNOW-659] Standalone SG2 fails to start, sigsegv in LLFastTimer
[14:09]	:	especially the heavy lifters (Aleric, Techwolf :) )
[14:10]	:	do you think we should roll back that 2.0.2 commit merge?
[14:10]	:	and sit on 2.0.1 code base for a while
[14:10]	:	I think internal should freeze their changes until they caught up with our 1.x patches.
[14:10]	:	(till we're done with SG1.x merge back)
[14:10]	:	:-P
[14:10]	:	I don't see why WE have to redo it for 2.0
[14:11]	:	With the snowglobe usage up, we need to get out at least one 2.x.
[14:11]	:	especially when it's unclear if THEN the changes will make it upstream or not
[14:11]	:	it will be a lot easier to try to catch up to a fixed version, we all seem to be spending way too much time chasing non stop obscure build bugs
[14:11]	:	Aleric: there are a lot of people moving things full speed in all sorts of direction, we have no choice but do things in parallel
[14:12]	:	and every merge seems to pull more in diverting attention from the porting the patches
[14:12]	:	we know we'd have to port
[14:12]	:	so +1 freeze for a short while, merge patches, get a release out there
[14:13]	:	OK, the issue *I*'m having is battling viewer-external merges all the time and, consequently, not helping on 1.x merge back
[14:13]	:	From what i've heard, too many showstopping like bugs in current 2.x trunk.
[14:13]	:	I know there are a lot of then I could expedite swiftly but I can't do that while doing merges all the time
[14:14]	:	it would seem a rollback to a fixed release then give ourselves a chance to regroup would be the logical answer
[14:14]	:	Yes, my point exactly Robin
[14:15]	:	At least tag a 2.0.1<?> branch so we can start working on a viable reliease and have something we can port 1.x code to.
[14:15]	:	K, silence is not necessarily consent so: who does *not* like that roll back plan?
[14:16]	:	well now, I have to believe that this silence is consent
[14:16]	:	:)
[14:16]	:	text chat takes a while
[14:16]	:	Either way is fine with me.
[14:16]	:	Nyx, some of that that 2.0.2 stuff in work is your multi-wearables, isn't it? Would it be possible for you to branch from snowglobe instead of from an internal branch?
[14:16]	:	I'm trying to be silent.. cause I don't have much constructive to say :/
[14:16]	 	looks at the revision graph.
[14:17]	:	my goal is to get that 1. port in there as fast as possible
[14:17]	:	so we can move to more interesting things...
[14:18]	:	and have a chance to get some of those patches in 2.1 (main viewer)
[14:18]	:	OK, it's settled then: I'll do the rollback
[14:18]	:	What I'd WANT is to make huge changes (I'd say, improvements) to the code... but I can't, I feel, which is very frustrating. And I can't because I stopped believing that such improvements would ever make it upstream, thus only increasing the merge load for you.
[14:19]	:	We're starting to get more and more people involved in Open Source now Aleric
[14:20]	:	see: 3 Linden here today :)
[14:20]	:	and we have Oz coming on board
[14:20]	:	I'm really hoping things will change
[14:20]	:	Is it possiabel to tag a 2.0.1 branch and commint/port to that?
[14:20]	:	but your point is well taken Aleric: we need to show with tangible actions that things are changing
[14:21]	:	(And since it seems that what comes from internal is breaking things more than otherwise, or horrible new "features" like 2.0... I believe the best thing for the open source project 'SG' would be to just fork and forget about "upstream"... but even that is not an option because some, like merov, are paid by LL )
[14:21]	:	Techwolf: we could but I don't see that as a big advantage. I'll still have to do a 2.0.2 merge later
[14:23]	:	"paid by LL" doesn't mean I can't contribute to GPL code
[14:23]	:	anyway, there are certainyl other ways to accelerate the rate of change in SG
[14:23]	:	agree
[14:24]	:	I guess Oz will be working on all those aspects
[14:24]	:	Where is Oz?
[14:24]	:	next on the agenda: new SNOW 666 to 670 tasks
[14:24]	:	If we truely fork, and start with major changes (for example.. we start with a source wide indent... we truely become independent from 'upstream'), then LL will say this project failed and you'd be taken off the SG project merov.
[14:25]	:	Techwolf: in Boston
[14:25]	:	I though the new linden be hrere today
[14:26]	:	Second day might be too soon, probably still struggling to get the whole dev environment up and running... :P
[14:26]	:	Techwolf: he told me he had issues with his LL avatar
[14:26]	:	"wardrobe malfunction" type may be :)
[14:26]	:	Has he been in SL before? Or does he have to learn the viewer?
[14:27]	:	If he is truely a newbie...viewer 2.0 is giving him/her a headace now.
[14:27]	:	:-)
[14:27]	:	He's been in SL before
[14:27]	:	k, on the 666 to 670 tasks, is there any takers for some of them?
[14:28]	:	I'm hoping Pixel will take 666 (she said she will already)
[14:28]	:	and Robin SNOW-669
[14:28]	:	http://jira.secondlife.com/browse/SNOW-669 [#SNOW-669] Port of SNOW-238 to SG 2.0 : Add Socks 5 Proxy Support
[14:28]	:	I can take SNOW-667
[14:28]	:	http://jira.secondlife.com/browse/SNOW-667 [#SNOW-667] Port of SNOW-93 to SG 2.0 : Automatic language translation of chat messages
[14:28]	:	\0/
[14:28]	:	thanks Thickbrick!
[14:29]	:	I don't know whether we'd have to re-do the accunt selection from scratch (SNOW-670). OpenSim and OGP users haven't been too happy with our solution, IIRC.
[14:29]	:	http://jira.secondlife.com/browse/SNOW-670 [#SNOW-670] Port of SNOW-129 to SG 2.0 : Select account from list at login
[14:29]	:	What I was planning on doing is going though the google doc list and snagging the simple stuff to get out of the way once a branch is desided on. (Currrnetly a rollback now)
[14:30]	:	Techwolf: if you do that *please update the spreadsheet* and *log a JIRA*!
[14:30]	:	Hahahah, jira? What that? :-X
[14:30]	:	I'm planning to do the same so we should avoid working on the same thing
[14:30]	 	has a bad habit of no changelog....:-/
[14:31]	 	feels he won't escape creating JIRA for all those little ones :/
[14:31]	:	k, I'll reate JIRA for those I'll take for sure
[14:32]	:	same here
[14:32]	:	Merov, i will need some input from others for UI layout for 669
[14:32]	:	Once I get my workflow set up on the correct branch, should be able to create and post patch for jira at once.
[14:33]	:	Look like the login information handling is changed in later revesions.
[14:33]	:	Robin: sure, someone is cleaning some wiki doc on the new XUI BTW
[14:33]	:	should be avialable soon
[14:33]	:	cool
[14:33]	:	great
[14:34]	:	k, so we have 3 of those "big" one assigned, I can take SNOW-668
[14:34]	:	http://jira.secondlife.com/browse/SNOW-668 [#SNOW-668] Port of SNOW-352 to SG 2.0 : Add optional double-click teleport
[14:34]	:	(easy one I think)
[14:34]	:	SNOW-670, may be wait till Pixel is done with 666
[14:34]	:	how's that for a plan?
[14:35]	:	shouldn't be much change in double-click teleport between 1.x and 2.x, except that it might use some improvments...
[14:35]	:	Is there any chance of having http://jira.secondlife.com/browse/SNOW-392 ported?
[14:35]	:	[#SNOW-392] llTextBox in client Non-Functional - Functionality Patch Attached
[14:35]	:	indeed, some XUI hacking though
[14:36]	:	Calcite: I need to commit to 1.4 before porting
[14:36]	:	that one
[14:37]	:	k, next on the agenda: lltexturefetch.cpp
[14:37]	:	that's a special tribute to Aleric :)
[14:37]	:	there was a *lot* of commits and patches by Aleric, Thickbrick and a little bit of myself in that code in 1.x
[14:38]	:	how comes patches get in partially, anyway?
[14:38]	:	merges gone wrong internally?
[14:38]	:	meh, i spend ages de-deadlocking texturefetch as well -;p
[14:38]	:	some have been taken in, some not, some were done in a different way
[14:38]	:	oh, this is about several patches, then?
[14:38]	:	sorry about forgetting you Robin
[14:39]	 	smiles
[14:39]	 	remembers
[14:39]	:	I looked into th patches and v2.0 code and clearly, we can't apply the patches blindly and hope it'll work
[14:39]	:	certainly not with the mutex patches, they will need reassessing
[14:40]	:	this need some deep analysis, what I wrote as "audit" (may be not a good word but you see what I mean)
[14:40]	:	helgrind is the wayforward
[14:40]	:	there's also a new codepatch to experiment with: http-textures
[14:40]	:	dunno if helgrind finds everything, but it might help for sure
[14:40]	:	*code path
[14:40]	:	thread/mutex/concurancy debugging on valgrind
[14:41]	:	actually, following that work Aleric made a proposal some weeks ago to make mutex dead locking less of an issue
[14:41]	:	Aleric, have you been working some more on that idea?
[14:42]	:	You mean the automatic detection of the order in which mutexes are locked?
[14:42]	:	thats also a helgrind function
[14:42]	:	I think he means the class template.
[14:42]	:	that and the new set of classes you proposed
[14:43]	:	IIRC you proposed to put the shared data and mutex into a single class, maing clear what mutexes control
[14:43]	:	Oh yes that... no that got interrupted by the TPV policy debacle... and ever since I've worked on other things that now need my attention (want to finish what I started)
[14:43]	:	understood
[14:44]	:	well, looking at the old and new code, I see SG 1.x did a binch of changes to make things cleaner / less dead lock prone and that has not all been ported
[14:45]	:	I agreed though with Aleric's point that that code needed more than just "debug/fixes" but some serious rework
[14:45]	:	with http-texture on beta thats a good target for falling over deadlocks in texture fetch
[14:45]	:	so I was thinking about starting something around it, keeping as an objective to make that code more stable and perform better
[14:46]	:	k, I'll unearth your email Aleric and use it as a starting point for a new conversation on opensource-dev
[14:46]	:	Merov: ... that sounds great... but what sense does it make to make *major* changes like that if it's not going to be used by upstream? It will become a maintenance nightmare
[14:48]	:	you're right... so I'll go an pull the devs in so that we can have that conversation with them, or some of them, directly...
[14:48]	:	anyway, if we show that SG performs better, they'll get an incentive to take our patches... :)
[14:48]	:	well at least i made it for the last part of the meeting
[14:48]	:	i think its time for some more of those graphs i did ;-)
[14:49]	:	yes, that was a question I had Robin
[14:49]	:	how did you do them?
[14:49]	:	could we get some metrics like that automatically extracted?
[14:49]	:	monitor viewer stats and save them every second to lists, then just write them to a file
[14:49]	:	that would be great to measure progress
[14:50]	:	in fact it was a patch i stole out of imprudence then hacked up a little
[14:50]	:	cool!
[14:50]	:	heh, I could drag out my last year project that did some client side performace testing and mesurments.
[14:51]	:	I was told that it was being done internially, but I havn't seen or heard a peep sence then.
[14:51]	:	well, having some measurement on perf we all agree on would sure help focusing perf improvement efforts
[14:51]	:	but as i said simply saving viewer stats such as texture queue FPS, bandwdth etc was all i did
[14:51]	:	So I dropped the project and went onto other things.
[14:52]	:	Zen was asking me to repeat on latest 2.X as the pipe line was improved
[14:52]	:	interesting
[14:53]	:	if we could get such numbers for each iteration that would be great
[14:53]	:	repeatability and reproducability are the biggest issues
[14:54]	:	as always with overall perf measurement
[14:54]	:	Really need some test regines setup just for this.
[14:54]	:	better than hear say though...
[14:54]	:	well they say there are lies dam lies and statistics
[14:55]	:	but they could be useful but we do need to be careful with the results
[14:55]	:	Real improvements come from change of algorithms, not (manual) optimization. That means in our case radiacal changes in how things are achieved, and those can be thought up without measuring too.
[14:55]	:	Lag spikes are worse then slow but steady framerate.
[14:55]	:	looks like im going to have to read the log of this meeting
[14:55]	:	could you make the results you gathered so far public Robin?
[14:55]	:	Speaking of which, any way we can see viewer usage statistics?
[14:56]	:	That's topic 2.2 on the agenda
[14:56]	:	Ardy: I need to ask internally, not sure
[14:56]	:	I expect the answer to be "HELL NO!"
[14:57]	:	(For example... I'd think of a ccache-like system between prim-level data and ready-to-send-to-the graphics card "compilation" there off. That would speed up animations (which repeat themselves), but also, for example, Latha's tail movement. It would be pre-compiled say.)
[14:57]	:	Hah, I still have the results I did last year up. http://gentoo.techwolf.net/performance/
[14:59]	:	there are certainly more than one place for perf improvement for sure
[14:59]	:	I agree that often, a radical change in the algo is required (case in point: the map changes I did...)
[15:00]	:	(Aleric, that sounds like display lists in OpenGL... Might want to think in groups bigger than prims, but it gets hard to activate many textures simultaneously on the graphics card, need to palletize them somehow...)
[15:00]	:	Somebody has started work on texture atlasing.
[15:00]	:	I think that right now, we the easiest way to get a really big improvement, is to concentrate on using the other cores :p ... But then I ignore that LL wants to support the apparently 90% of the users with a 486 on 50 Mhz.
[15:00]	:	s/we//
[15:01]	:	he
[15:01]	:	the autmatic atlasing in 2.0 kind-of-almost works
[15:01]	:	yeah: class 0 machines can't ne brushed aside... that's biting us...
[15:01]	:	time check: 3pm already
[15:01]	:	Merov, any docs on what class machine is what number?
[15:02]	:	I think that's an internal classification, not of much value
[15:02]	:	just saying that class 0 are the bottom of the barrel and there are *a lot* of them out there...
[15:03]	:	Deferred rendering makes them all feel like class-0 machines.
[15:03]	:	I know a great many SL users using laptops.
[15:03]	:	laptops don't need to be class 0
[15:03]	 	has a MacBookPro... not class 0... :)
[15:03]	:	some of the nvidia mobile GFX cards are pretty good
[15:04]	:	hardware imporovments have slowed down in the past years. Years ago, a new system was usally 5 to 10 times faster. Today, a three year old system is less then 2x slower then a new system.
[15:04]	:	Intel's still the biggest supplier of graphics last I checked, though, thanks to their Geforce 2-level cheap integrated stuff... :(
[15:04]	:	anyway: throwing hardware at the problem is not something we can do: we have to work on what resi have
[15:05]	 	waiting for memristors architecture to become main stream...
[15:05]	:	heh
[15:05]	:	that'll take a while :)
[15:06]	:	k, I think we reached time limit
[15:06]	:	The current imporvments in hardware are more engery effect cores.
[15:06]	:	What are Pastrami and Runitai up to lately?
[15:06]	:	we didn't address point 3 which is very interresting so need to table that for Thursday
[15:07]	:	2.1 wasn't adressed, either (partially discussed last Thursday, I think)
[15:07]	:	Ardy: I really prefer having people talk about their stuff themselves, I hate to misrepresent what people do
[15:08]	:	I was thinking the were from Windward Mark and worked on rendering.
[15:09]	:	yes, they do work on rendering, that's not saying much though :)
[15:09]	:	Yeah, okay.
[15:09]	:	There aren't many graphics-related things lately in the blog posts though, so it does narrow things down a bit :P
[15:09]	:	652: I'll ping the securoty minded folks on this one
[15:10]	:	Meh, revision graphing is broken on SVN stuff starting with all the V2 work.
[15:10]	:	I think there's also other app/ uris that might be a problem
[15:10]	:	Totally useless.
[15:10]	:	k, need to wrap up and go
[15:11]	:	All branches are displayed as seperate projects.
[15:11]	:	Thanks Merov :)
[15:11]	:	I do hope that Oz will have his avatar fixed by Thrusday and will be here next time
[15:11]	:	\o/
[15:12]	:	We're getting a backlog of meeting topics, it seems
[15:12]	:	some, true
[15:12]	 	tries to find the real head of the V2 repository.
[15:12]	:	I do feel we discuss the important things though
[15:13]	:	at least, I feel those meetings are useful to me
[15:13]	:	what about you guys?
[15:13]	:	Yes
[15:14]	:	Indeed, I am merely observing though, but it is insightful
[15:14]	:	Oh one thing Merov, we are on a deadline for the SL7B submission
[15:14]	:	they're certainly useful, it's just that I'm too much of a sloth to do stuff outside the meeting
[15:14]	:	im here to try and help and to learn as well
[15:14]	:	eeew... what's the deadline?
[15:14]	:	when are we dead?
[15:15]	:	Ah, found it. Was renamed. Drat. SG2 is still seperate. Oh well.
[15:15]	:	20th
[15:15]	:	meh
[15:15]	:	oh
[15:15]	:	that's soon
[15:15]	:	Yahuza!
[15:15]	:	I though they start taking apps on the 20th?
[15:16]	:	There was only a short opening for applications
[15:16]	:	I'll email Oz now
[15:16]	:	what do we need till the deadline? only the application?
[15:16]	:	# LL will start accepting applications - 12th May 2010
# Deadline for applications – 20th May 2010
[15:16]	:	yes just an application 100 words or less saying the kind of thing we are about
[15:16]	:	and a name or too
[15:16]	:	I talked to Howard about it BTW and he thought it was a good idea
[15:17]	:	Shall i just put an application in?
[15:17]	:	just want to make sure Oz is on board too
[15:17]	:	let me email him and cc you, ok?
[15:17]	:	if all aligns, we'll make a wider announcement on the list
[15:17]	:	sure
[15:17]	:	cool!
[15:18]	 	wonders why i'm just not on the payroll the number of LL emails i get day
[15:18]	:	OK, need to go now
[15:18]	:	what application?
[15:18]	:	see you Thursday, same time
[15:18]	:	bye!
[15:18]	:	SL7B display for Snowglobe project
[15:18]	:	for a stand at the 7th birthday exihibition
[15:19]	:	see you
[15:19]	:	What would you want to show on a stand in-world??
[15:19]	:	we don't know, yet, I guess
[15:19]	:	well other viewers have stands, open sim had a stand
[15:19]	:	Think of it as marketing :P
[15:20]	:	its more about awareness and presence there will be lots of people there who know nothing of snowglobe or ud
[15:20]	:	*us
[15:20]	:	marketing... okeeey
 
Generated with SLog Wikifier