Open Source Meeting/2010-03-04

== Agenda Thursday, 04 March 2010 ==
# Weekly Snowglobe update - Merov Linden
# Finalize 1.3
#* outstanding bugs?
#* test sprint required?
#* RC2 ready to be the release?
# : create a BINDIST CMake variable for producing (hopefully) legally distributable binaries
#* Not answered at last meeting: Could we get LL's legal department to cooperate on this one, so we can minimize the guessing on what the required steps are?
# Snowglobe 1.4: bug triaged in the community, tree's open, commits coming?
#* "commits coming?": looks like not anymore ...
# Snowglobe 2.0: what the heck was Merov doing?
#* Snowglobe 2.0 Source code issues, many with patches (see SNOW 2.0 Source Code issues on pJIRA)
#* How to handle ports from Snowglobe 1.x to 2.0?
#** For now, we've opened separate issues, so status can be tracked independently. (We don't want to mess up the 1.x release process by reopening stuff that is and stays fixed in 1.x)
#** Should we still include the original issue IDs in contributions.txt, so that diff can be used to see what still needs to be ported?
# What is the official answer about source drops for non-Snowglobe 2.x? (Yes/Later/No) --Thickbrick
#* Answers so far were too vague (Howard Look's email)
#* If the answer to 6. above is "No," where does it leave us WRT:
#** Making sweeping changes in Snowglobe (e.g. UI changes diverging from LL decisions, infrastructure changes, etc.)?
#** Upstream diverging from Snowglobe. Likely, unlikely?
# [2010/03/03 08:13] Q Linden: I have beeen in a number of snowglobe triages, and most of the time when we don't import a bug fix it's because the fix is either a local fix to a global bug, or a viewer-side patch that papers over a server-side problem.
== Transcript ==
[14:04]	:	can we start guys?
[14:04]	:	I think so
[14:04]	:	looks like we have a quorum
[14:04]	:	First, a link to the angenda please.
[14:04]	:	it's on the wall
[14:04]	:	:)
[14:04]	:	We were NOT ignored. We were told the changes we were protesting were a foregone conclusion and to focus on debugging.
[14:04]	:	http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda
[14:05]	:	OK, Finalize 1.3
[14:05]	:	Thank you, Robin.
[14:05]	:	I triage 44 unscheduled bugs and look in the coming bunch
[14:06]	:	Techwolf, in SG 1.3 enable MediaOnAPrimUI. That gives you a 2.0-like UI to pop the land media into a browser.
[14:06]	:	and, so far, no new 1.3 bugs that could be considered as show stoppers
[14:06]	:	one reported today, but I don't think it's a showstopper (SNOW-551)
[14:06]	:	http://jira.secondlife.com/browse/SNOW-551 
[#SNOW-551] -loginuri command line argument converted to lower case
[14:06]	:	so, if everyone's fine with it, I'd like to call it a wrap and make that last 1.3.2 the official Snowglobe
[14:07]	 	has been running 1.3.2 RC for the entire week with no issues.
[14:07]	:	yea 551 causes some OGP breakage but certainly not a snow stopper
[14:07]	 	looks for pixel
[14:07]	 	looks at 551
[14:08]	:	Pixel, Hurli came in to opensl a bit grumpy earlier ;-)
[14:08]	:	he seems to be that way a lot.
[14:09]	:	i guess it broke a launch thingie
[14:09]	:	so it was put into lower case to put into the history file?
[14:09]	:	I've been trying to keep up with all the bug reports and patches, but things are just moving so fast on me. :-)
[14:09]	:	seems silly
[14:09]	:	yes
[14:10]	:	that would be an issue for any OpenSim user, me thinketh
[14:10]	:	as far as I can see, we can just remove those 2 lines of toLower, but that needs testing and I think we're too late in the 1.3 cycle for that
[14:10]	:	on the face of it, seems like something pretty common for folks using OGP-login
[14:11]	:	Who are the folks using OGP-login? It would be good to know so people could talk to each other.
[14:11]	:	be careful just removing those lines, it will probably upset the login history that aleric added, i suspect it needs a comparison done under is_lower() but storage nativly
[14:11]	:	Morgaine: that's why I was asking Pixel
[14:12]	:	I think the comparison is only done on the host part of the URI (LLURI::getHost)
[14:12]	:	Oh I know Pixel's using it, she wrote the thing. :-)) I mean who else.
[14:12]	:	maybe just the domain part of the URL should be lowercased?
[14:12]	:	not a lot. me, Hurliman, Lindenites, and a few others doing occasional testing
[14:12]	:	why should *any* of it be changed? it's a URL!
[14:12]	:	Hmmm... seems few to hold 1.3
[14:13]	:	Hurli uses Snowglobe with OGP-login?
[14:13]	:	yes
[14:13]	:	me thinks so a little
[14:13]	:	not that we can still do a 1.3.3 later..
[14:13]	:	Cool, I'll talk to him sometime
[14:13]	:	it can break for login to non-OGP 3rd party grids, but I don't think any major ones use a URI that is sensitive to this.
[14:13]	:	Morgaine: try to catch him in a good mood. :)
[14:14]	:	yeah, i think thick is right.
[14:14]	:	He's always in a good mood with me.
[14:14]	:	I only tried personally to login to OSGrid, though.
[14:14]	:	Morgaine: doh!
[14:14]	:	Merov: go forth and prosper with 1.3.2
[14:15]	:	we're coders so we deserve to be talked down to...
[14:15]	:	Morgaine: have u ported SNOW-129 to the Snowglobe 2.0 codebase?
[14:15]	:	http://jira.secondlife.com/browse/SNOW-129 
[#SNOW-129] Select account from list at login
[14:15]	:	anyway, OK, I'll flip the switch on 1.3.2
[14:15]	:	if so, can you change it to not do the lower casing?
[14:16]	:	Pixel: why would I port anything to the Snowglobe 2.0 codebase before all the closedness and client-side scripting and TPV issues are resolved?
[14:16]	:	woops. Morgaine, Merov.. can't think straight today
[14:16]	:	Pixel: nope, not yet
[14:16]	:	Merov: have u ported SNOW-129 to the Snowglobe 2.0 codebase?
[14:17]	:	ok
[14:17]	:	Easy mistake to make, cranky Frenchman and cranky Brit. There's only a channel between us, you know. :-)
[14:17]	:	No, I haven't :)
[14:17]	:	when u do, plz undoodle the lower casing. (eventually pixel will catch up to the conversation)
[14:17]	:	There's a reason I move to the other side of the planet...
[14:17]	:	Haha
[14:17]	:	heh
[14:18]	:	anyway, enough with 1.3 I think
[14:18]	:	next
[14:18]	:	SNOW-495
[14:18]	:	http://jira.secondlife.com/browse/SNOW-495 
[#SNOW-495] BINDIST --- easy way to produce legally distributable binary packages
[14:19]	:	I'm all in favor of doing this work
[14:19]	:	I'm not sure what legal has to do with it though
[14:20]	:	legally distributable as in GPL compliant
[14:20]	:	possibly also TVP compilant would also be revelant with branding and logos etc
[14:20]	:	Snowglobe is a LL trademark
[14:20]	:	also I'm not sure if we can package the vivox stuff
[14:20]	:	legil has to tell us what files are owned by LL in way of trademark and so on.
[14:20]	:	GPL compliancy is all about making the source code available
[14:21]	:	its also about not linking to non-free binaries eg KDU and distrbuting
[14:21]	:	Ha! Snowglobe trademark, I saw that (different record though)
[14:21]	:	there's more to ditribution than copyright.
[14:21]	:	Merov: GPL compliance is about a lot more than that. GPLv2 clause 6 is about guaranteed developers freedoms to modify and distribute.
[14:21]	 	mumbles Iceweasel
[14:21]	:	heh
[14:21]	:	i bag Iceglobe
[14:22]	:	i guess i would opt to change the jira name to "easy way to produce distributable binary". lawyer will cringe at 'legally distributable'
[14:22]	:	OK, on the (tm), I've been discussing with legal on this this morning
[14:22]	:	well, I've put "legally" in it to distinguish from "will run everywhere you unpack it"
[14:22]	:	(Iceweasel = http://wiki.debian.org/Iceweasel )
[14:23]	:	not settled yet but so it's hard to discuss what my opinion is (my opinion is not helpful and eventually irrelevant)
[14:23]	:	but, yes, I'm working intenally to get this cleared up
[14:23]	:	think of the mozilla fiasco on debian please
[14:24]	 	heard about that
[14:24]	:	we've been here before though as well
[14:24]	:	but OK, I hear you now
[14:24]	:	this is the 2nd time around this loop
[14:24]	:	And think of the BSD advertising clause fiasco too please, which took many more years to resolve than iceweasel. "No further restrictions" is an important clause of the GPL.
[14:24]	:	iceweasel, oppisite of fire and the personally of the mozilla group.
[14:25]	:	Also, the cutest logo of any browser.
[14:25]	:	(Check GPLv2'FAQ for more info on that)
[14:25]	:	FireCubiod then?
[14:25]	:	In any case, a nice build system that would guarantee what all logo, tm, license issue are cleanly dealt with would be good
[14:25]	 	nods
[14:25]	:	SteamCube.
[14:26]	:	so working on SNOW-495 is good no matter what
[14:26]	:	"guarantee" not in the legal sense, though. Neither the community nor LL could do that, I guess.
[14:26]	:	;-)
[14:26]	:	"Help ensure"
[14:27]	:	yeah
[14:27]	:	so I guess the answer to the "what the next step is?" question is "Merov dealing with LL legal to resolve Snowglobe tm issue"
[14:27]	:	at least that's a first clear step
[14:28]	 	hands Merov her sympathy
[14:28]	:	The build sytem would just leave out the non-distrubitiable files and its up to the packager to add there own files to prevent runtime errors.
[14:28]	:	k, next: SG1.4
[14:28]	:	the tree (2009 trunk) is open for commits
[14:29]	:	I haven't committed to it true
[14:29]	:	i've committed a couple of things on 1.4/trunk, mostly some build tweaks though nothing really exciting
[14:29]	:	and I know that other committers are busy with SG2.0 hacks
[14:29]	:	i think i've now rolled those same commits in to 2.0 anyway
[14:30]	:	Will we see parts of 2.0 in 1.4?
[14:30]	:	I told before I'd do a weekly 1.4 build
[14:30]	:	Wow, I was just thinking about Thick's "cutest logo of any browser", and it occurred to me, if that same person who designed the Snowglobe logo were contracted to design the widget textures for Snowglobe-2.0, that would be epic.
[14:30]	:	I didn't last week as I fixed the build for 1.3
[14:30]	:	Time permitting i'm all up for keeping 1.x going for a little while anyway
[14:31]	:	Robin: +1, at least as a contingency branch in case of horrible mishap
[14:31]	:	LL do seem to reapidly switch viewer versions and force upgrades when there are major changes that take time to adjust too
[14:31]	:	so keeping a SG 1.x around will make that transition easier
[14:31]	:	+1
[14:31]	:	yes, it's not more work for me to keep this open, really
[14:32]	:	I'll triage my 1.4 bugs
[14:32]	:	i considered in a moment of madness some backports from 2.0
[14:32]	:	I've been a tad busy in the last 2 days triaging bugs right and left though
[14:32]	:	Well can't use Snowglobe-2.0 until its speed issues are resolved. 2 FPS where Snowglobe-1.x does 20 FPS is a showstopper for active events.
[14:32]	 	feels he's living in JIRA
[14:32]	:	2 FPS!
[14:33]	:	'Fraid so. Senf-compiled on Linux-32
[14:33]	:	Yes, I am having to say with Snowglobe 1.4.0 for several reasons.
[14:33]	:	Self*
[14:33]	:	It might be nice to be able to get the script usage window to display in 1.4
[14:33]	:	I'm using SG2.0 right now and it's spiffy (Mac)
[14:34]	:	I'd like to try a standalone compile incase the speed problem is something to do with the new library deps. But I hear that standalone builld is troublesome currently.
[14:34]	:	Jonathan: you're asking to backport a SG2.0 feature to the 1.4 code base?
[14:35]	:	Somebody just added several thousand scripts to this region.
[14:35]	:	Morgain, i've had standalone goinging since day 2, but no media
[14:35]	 	grumbles about qtwebkit
[14:35]	:	Yes. I have heard people asking for that--perhaps it's too difficult though, or will turn up in other viewers
[14:35]	:	other viewers can back port from the published SG2.0 code
[14:36]	:	nothing prevents them to
[14:36]	:	I've been trying to fix the last of the standlone bugs. Some patches are in some jira, some mine.
[14:36]	:	Using Viewer 2.0 is like herding 12 Jack Russel Terriers. Too much jumping and bouncing around.
[14:36]	:	Could I ask why it's no longer possible to delete glib and gobject .so's from the prebuilt directory? It objects violently, and insists to have them there. The only option is to slam the platform's .so's on top of the prebuilt ones.
[14:36]	:	The biggest obstickale to my local system and everyone else for that matter is the missing llqtwebit files.
[14:37]	:	Merov, do we have an ETA for that, if its going to be a while i can probably cook something that works out of the source we already have
[14:37]	:	(In 1.x you could just delete them, along with a pile of others)
[14:38]	:	that being: llqtwebkit?
[14:38]	:	yes
[14:38]	:	Morgaine, is it doing apr_dso_load() on them i wonder?
[14:38]	:	gstreamer?
[14:39]	:	I know that the media team is working on cleaning up their act wrt their posted GPL code
[14:39]	:	Robin: no way, one doesn't dlopen() glib and gobject
[14:39]	:	don't know the ETA
[14:39]	:	I'me tempted to see if there is a way to diable llqtwebkit/qtwebkit/webkit during the build and just forget anywebkit functions.
[14:39]	:	but it's hot on their list
[14:40]	:	BTW, I saw an anouncment the other day the QtWebKit will start having releases independant of Qt - that probably means easier to build.
[14:40]	:	ok, i can wait, the missing API is pretty trival and just some keyboard/mouse events, i could hotwire them and get it working 99% but if its soon i wion't bother
[14:40]	:	k
[14:40]	:	llqtwebkit and qtwebkit are two complety different packages.
[14:40]	 	hints that llmonroe on #opensl just _might_ have been on the media team ;-)
[14:40]	:	yes, but vanilla QtWebKit still needs some patches, right?
[14:41]	:	Techwolf: true, llqtwebkit is our wrapper around it
[14:41]	:	There's no protection on MoaP-caused local executions currently anyway, so best to not run with MoaP enabled until something'is done about security.
[14:41]	:	Thinkbrick, I have use sytem qtwebkit without issues on snow 1.x.
[14:41]	:	and Thickbrick is right too: we have patches to qtwebkit
[14:41]	:	merov, i patched llqtwebkit to work around those patches
[14:41]	:	heh
[14:42]	:	some pushed back to them but it'll take time for them to take them
[14:42]	:	so we'll need to post our qtwebkit hacks somewhere
[14:42]	:	so we could use distro qt4, the functionality loss is so minor no one has yet noticed, its a history prepend patch and one other i forget
[14:43]	:	The patches on qtwebkit are minor, but it request building the entire qt package and that can cause problems at its a huge and complex sytem. Just look at the gentoo QT ebuild to get a sence that there more then just running qmake.
[14:43]	:	Morgain, sandbox llqtwebkit in a chroot and connect via a tcp socket to the chroot, should be pretty safe ;-)
[14:43]	:	Morgaine: since every face with a media URL on it goes through a capability before the viewer gets the URL, LL can have a killswitch for it. And apparently, they do.
[14:44]	:	Isn't that an OS specific solution?
[14:44]	:	Ardy, run a linux box, specifcily for sandboxing llqtwebkit next to your windows/mac box ;-)
[14:44]	:	runs on any OS that has chroots ;-)
[14:44]	:	What if the url is put through tinyurl or friends though?
[14:44]	:	Robin: lemme quote about 1000 people in a recent exchange about chroot: "Chroot is not a security solution". And that included the inventor of chroot.
[14:45]	:	Not a useful answer for many people. Remember who LL's target audience is.
[14:45]	:	agreed
[14:45]	:	Joathan, the kill switch is global. It kills all url. It not set up as a filter.
[14:45]	:	Thanks Tech--that wasn't made clear at the media OH yesterday
[14:45]	 	wonders if we should go back to the agenda... see people running to the next meeting...
[14:46]	:	Merov+1
[14:46]	:	2.0: there are a couple of interesting questions in the agenda
[14:46]	:	+1
[14:46]	:	patches: yes, I've been triaging a bunch and, if you have commit access, please go ahead and commit!
[14:47]	:	I think there is just one commiter here.
[14:47]	:	for those who don't, ask me if unassigned or ping me if assigned to me and I'm sitting idle on it
[14:48]	:	now: the 1.x to 2.0 ports
[14:48]	:	I think it's bettte to open separate issues
[14:48]	:	it signals to all who's working on what
[14:49]	:	Is there a way to flag a jira that has a patch ready for review by a commiter?
[14:49]	:	so we're not duplicating work
[14:49]	:	yes: patch attached
[14:49]	:	that's the flag I check for sure :)
[14:49]	:	Merov, so far we have been opening new jira's for things previously committed on 2.0 and marking them as duplicate with an approprate comment
[14:49]	:	committed on 1.X
[14:49]	:	I saw that and I approve of it
[14:49]	:	:)
[14:50]	:	next subquestion: Should we still include the original issue IDs in contributions.txt, so that diff can be used to see what still needs to be ported?
[14:50]	:	Ok. I was wording about that due to I had to re-do or update a patch and re-submite.
[14:50]	:	I would say "yes, do not edit the contributions.txt unless you add something"
[14:51]	:	this is a way to acknowledge work anyway
[14:51]	:	it also helps to quickly know "is this patch in there or not?"
[14:51]	:	and one could argue there's as much work on some stuff in writing the priginal patch and porting it
[14:51]	:	the old 1.x contrinutions are missing because 2.0 was forked off from a different point/before snowglobe so it has none of the previous contributions currently
[14:51]	:	so both are legitimate to acknowledge
[14:52]	:	so we can add in the old one that has been effectivly lost
[14:52]	:	oh that! you're right!
[14:52]	:	silly me
[14:52]	:	Whee...I'll have two entris for one patch of mine. lol
[14:52]	:	:-P
[14:52]	:	yes, we should "merge" the original contribution.txt
[14:53]	:	the diff should show us whats missing and needs work
[14:53]	:	OK, I think I muddled the issue but I think I made the intent of contributions.txt clear :)
[14:54]	:	well, i need to go on aditi, for now sorry! but nice meeting ㋡
[14:54]	:	So if one got a patch accecpted and didn't get ported over, the oraingle contrube.txt entry plus the new entry for the porting work is ok?
[14:54]	:	I don't think any of my small number of contributions carry over as I was just fiddling with little UI oddities, trying to get a feel for the codebase.
[14:55]	:	Techwolf: yes, you get 2 entries
[14:55]	:	even if something is not now/will not be in 2.0 does not mean the work was not done, there should still be a record in there
[14:56]	:	Ardy: in that case, I still feel the entry should be there, if nothing else, that siggnals that we "ported", even if nothing needed to be done
[14:56]	:	+1 Robin
[14:56]	:	as a dev, I know that some of my work will be wiped out by others later
[14:57]	:	that's life in an organic medium like "code"
[14:57]	:	OK, next: the missing "vendor" branch
[14:58]	:	(ot: what the hot key to select a grid from login on viwer 2.0?)
[14:58]	 	rolls drum
[14:58]	:	yes, we will have a vendor branch
[14:58]	:	o/
[14:58]	:	ctrl shift G?
[14:58]	:	Tech: probably Ctrl+Shift+G
[14:58]	:	that's very good to hear!
[14:58]	:	That got it. thanks.
[14:59]	:	so explain vendor branch to the uninformed
[14:59]	:	vender branch?
[14:59]	:	native 2.0 code export
[14:59]	:	there was some confusion up and down and I need to confess I muddled the water with releasing only a SG2.0 one
[14:59]	:	that was really for expediency
[14:59]	:	but then, that turned into a bigger question
[15:00]	:	oh, you mean code matching the mainline viewer binaries?
[15:00]	:	that's cleared though now
[15:00]	:	right
[15:00]	 	hugs Merov
[15:01]	:	was there som edisagreement inside Linden on that, or was it just a matter of it falling between the cracks?
[15:01]	:	Techwolf: with a bit of luck your blog post question will get answered then soon
[15:01]	:	so, life in 2.0 will be no different than life under 1.23
[15:01]	:	its good for snowglobe development to be able to diff against the stock code as well
[15:01]	:	or 1.x
[15:01]	:	that's awesome news.
[15:01]	:	Robin: big +1 a!
[15:02]	 	returns and catches up on chat...
[15:02]	:	OK, there's one item left (7) and we're 3 min late
[15:03]	:	I put 7 there as it answers a question that was asked in IRC.
[15:03]	:	that makes the rest of question 6. irrelevant... Very good!
[15:03]	:	o/ LL actually came to there sences.
[15:03]	:	That quote from Q is correct in general
[15:03]	:	what is making problem with it?
[15:04]	:	It would be nice to know that a problem we are working on is really out of our domain.
[15:04]	:	i need to tweet the good news abt viewer 2.0 source.
[15:05]	:	I'm replying to that without context (so possibly irreleavnt), but I think it's best to comment somehing like that on the original pJIRA, so the patch submitter can try to address it.
[15:05]	:	Why is it needed to trawl blog posts and OH transcripts to get an answer to simple questions like this? Just bizarre ...
[15:05]	:	Morgaine: I'll post something to opensource-dev later
[15:06]	:	Thanks Merov
[15:06]	:	actually, I should blog about it also but I'm waiting to have things cleaned up script wise before doing this
[15:06]	:	I'm still doing part of the process "manually" which sucks...
[15:07]	 	can imagine
[15:07]	:	When you read answers to simple questions like Techwolf made on the blog to Dessie, and Carl replies in a way that obviously avoids the question, it starts a lot of people talking. And that doesn't help anyone.
[15:07]	:	I'd like 2 days of focused hacking just to finish them...
[15:07]	:	Merov: you've been doing a bang up job of holding the ship together recently.
[15:07]	:	no interruption!
[15:08]	:	I keep a Zen like attitude Pixel :)
[15:08]	:	I think it was more that Carl was trying to be helpful without knowing the full context
[15:08]	:	That's where being French and used to people haggling on anything helps..
[15:08]	:	haha
[15:09]	:	i keep a red-wine like attitude. .... and with that... it's time for a glass of Cab. Cheers, Hippos!
[15:09]	:	Cheers!
[15:09]	:	lol. I can immagine being the public facing target for all the community grumpyness isn't fun.
[15:09]	:	time to go for me too
[15:09]	:	TC Merov, and chin up :-)
[15:09]	:	UXIG time
[15:10]	:	Back to more magnetic hedgehogs ;-(
[15:10]	:	Beta grid OH going on too
[15:10]	:	Thickbrick: a better more patient attitude wouldn't hurt
[15:10]	:	anyway, I don't held grudges
[15:10]	:	"Damn the torpedos! Full ahead!" did work, after all. He only lost the one ship.
[15:10]	:	bad karma
[15:10]	:	we'll try next time...
[15:10]	:	Merov, do you see *how* much coffee we drink ;-)
[15:11]	:	TC all :-)
[15:11]	:	bye!
[15:11]	 	looks at the fridge full of Koolade.
[15:11]	:	bye!
 
Generated with SLog Wikifier