Open Source Meeting/2010-04-13

== Transcript ==
[14:06]	:	Well, I am not gonna distribute anything. I might contribute trivial patches via pJIRA, that all.
[14:06]	:	So here I am.
[14:06]	:	Looks like that rounded up a few
[14:06]	:	=)
[14:06]	:	hey
[14:07]	:	ok, well, I didn't prepare an agenda
[14:07]	:	SG2.0 trunk did build on all platfroms yesterday night!
[14:07]	:	W00t!!
[14:07]	:	woot
[14:07]	:	nice
[14:07]	:	thanks a lot to Thickbrick and Techwolf
[14:08]	:	... I was kayaking!
[14:08]	:	Mainly Techwolf...
[14:08]	:	the remaining problems now are:
[14:08]	:	1) it doesn't send an email with the links to the produced binaries
[14:08]	:	update libuuid =)
[14:08]	:	I'me here....but text only.
[14:09]	:	2) the names of the packages for Linux is not correct
[14:09]	:	I also wanted to take the "SNOWGLOBETESTBUILD" suffix added to the Mac version
[14:09]	:	does someone remember?
[14:09]	:	I don't remember why we added that...
[14:10]	:	o, thanks lag for inversing my sentences in chat...
[14:10]	:	I never got a notice in IRC that the build passed. ie:not failed.
[14:10]	:	So my patch worked and I found out today.
[14:11]	:	yes ATechwolf, that's what I said...
[14:11]	:	Sorry, I got here late.
[14:11]	:	I know it passes because I can see the result logs and S3 place filled
[14:11]	:	Do we have access to that log?
[14:11]	:	the email didn't get sent though
[14:12]	:	One question I have, why is parabuild doing debug, releasedebug before the release that is packaged?
[14:12]	:	I can make and email "manually" giving all that
[14:12]	:	3313 need libuuid 1.3... I filed that here SNOW-606 ... if you built standalone you probably didn't notice this one... it only fails with newer libSM (X11) installs that tries to use the ll supplied libuuid when linked
[14:12]	:	http://jira.secondlife.com/browse/SNOW-606 
[#SNOW-606] link phase secondlife-bin fails; supplied LL-lib libuuid.so.1 needs to be upgraded
[14:12]	:	I found the mailing list on the web and was looking at the failed builds and noticed that.
[14:13]	:	ATechwolf: I don't know the reason of doing debug and relnodebug...
[14:13]	:	we're not posting the result of those
[14:13]	:	I'me folling two convoes, sorry for any delay.
[14:14]	:	hmmm... may be to ensure it builds in those 2 situations?
[14:14]	:	Ha, got the build log: http://s3.amazonaws.com/viewer-source-downloads/2010/trunk/3318/good-build.Linux
[14:14]	:	yea :-)
[14:14]	:	(byt guessing url)
[14:14]	:	good one Thickbrick
[14:14]	:	:)
[14:14]	:	not a secret for sure
[14:14]	:	Did you get 1.4 to build Merov?
[14:14]	:	and now, accessible for all :)
[14:15]	:	Aleric: good question and the answer is "no"
[14:15]	:	let me tell you the reason
[14:15]	:	we need the 1.23 bundles (the asset stuff) to build 1.4
[14:15]	:	I'me trying to move to the seats....if I run over somebody, sorry.
[14:15]	:	well, it just happen that those bundles on S3 are "cleaned" after 3 months
[14:16]	:	so we lost the old ones... :(
[14:16]	:	Techwolf, you're colliding with a signpost
[14:16]	:	So much for keeping supporting 1.23 and SG 1.x for another few years.
[14:16]	:	I'm trying to create new ones building again the oss-viewer branch and exporting it but parabuild and the whole build system moved so much that it broke
[14:17]	:	so I've been trying to fix that with CG
[14:17]	:	we passed build but have a problem with export
[14:17]	:	don't say "so much for", we are working to fix the problem
[14:18]	:	I and CG I mean
[14:18]	:	seriously
[14:18]	:	I really hope to be done with that shortly
[14:19]	:	once we get the 1.x export working again, I'll merge with SG 1.4 and build
[14:19]	:	I basically spend most of my days doing fix and launching parabuild tasks these days... :/
[14:20]	:	not fun... but necessary
[14:20]	:	I have a question :)
[14:20]	 	listens
[14:20]	:	Can you add "time" to that build? I'me courious on the build times. :-)
[14:21]	:	You mean: in the log ?
[14:21]	:	I can imagine, that is, it's not unlikely... that the number of patches that are added to SG, and not to the internal "official" viewer, will grow and grow and grow... I think that is going to be a problem in the future.
[14:21]	:	Yea. More of coursity then anything else.
[14:22]	:	What is your opinion about the fact that we have an "upstream" that is likely to diverge (is that's the right English word) more and more.
[14:22]	:	ATechwolf: we have that info (displayed in Parabuild) so I suppose we can output it
[14:22]	:	in the log
[14:23]	:	Aleric: the issue is about changes in SG that would never find their way in the main viewer
[14:24]	:	it's certainly an issue for some feature (VWRAP may be, though even that could be in the main viewer IMO)
[14:24]	:	but I think that Snowglobe should develop general purpose things that are intended to be in the main viewer from the get go
[14:25]	:	perf improvements, rendering improvements, etc...
[14:25]	:	Is that the opinion of the person who has to decide whether or not something will be added to the main viewer, too?
[14:25]	:	I think if someone had an idea about a really "out there" feature that has no chance to be in the main stream viewer ever, it should be done in a TPV
[14:26]	:	plugins
[14:26]	:	I think this is something we (the Snowglobe contributors) should decide collectively
[14:26]	:	I think snowglobe should aim to become the common base of TPVs, so if a feature is useful for most TPVs it should get into snowglobe, even if it has no chance to go upstream from there.
[14:27]	:	like: "yes, this feature is essential for any viewer, lets start here and push it"
[14:27]	:	or "no, this feature is interesting for some markets but not really mainstream, it should live in its own TPV"
[14:27]	:	Borsoodas, the flip side of that is that it prevents having half-done features that would be otherwise ok in a tpv, "because it's experimental"
[14:28]	:	hmm, true
[14:28]	 	thinks about that for a sec...
[14:28]	:	experimental, yet some standard is needed
[14:29]	:	in the big picture, I would like to see Snowglobe the code base for all TPV really
[14:29]	:	the one that every TPV uses to rebase from
[14:30]	:	One feature that is in nearly all tpv is the avatar_list floater. That is one featrue that all tpv have but is not going into the main client. Could snowglobe support a feature?
[14:30]	:	I don't believe in a one size fit all viewer for all needs on the planet
[14:30]	:	but a good common base will help everyone
[14:30]	:	Merov: example... I'm currently working on the following: I wanted to make the file chooser to not "time out" the viewer anymore (there is a jira on that). So, to not make the file chooser block the main loop. For that I made GTK threadsafe, and then needed to make the file chooser threadsafe. I wanted to that "re-usable", general, so I created a new class ThreadSafe that will allow general wrapping of any object to provide OO thread safe access, For THAT I needed to write a new class for read/write locking... and in order to do THAT right I needed an object oriented way to manage the APR pools... SO, then I started to work on refactoring the APR pools and wrote a class LLAPRMemoryPool... I'm currently working on a big patch that replaces the C-style apr_pool_t* with my LLAPRMemoryPool... have to fix several classes for that, like how LLSocket works etc....
[14:30]	:	that's what I'd like to make happen with Snowglobe
[14:31]	 	just got drowned out by Aleric. :-)
[14:31]	:	My problem is: All this is pure good "refactor" stuff, making things more robust and maintainable. So it SHOULD go into the main viewer... But what if some internal dev things: OMG a 300 kB patch! No time to review...
[14:31]	:	but I don't feel like merging all this EVERY time....
[14:31]	:	Aleric, the things you are doing are not "out there" features they are core rewrites of important stuff that could help stability, new code in the future etc, although its tricky it needs to go upstream
[14:31]	:	well, first, I think we *need* that refactor in our code :)
[14:31]	:	If it doesn't go into the main viewer... then I don't want to continue to maintain it
[14:32]	:	maintaining big changes like that permanently is crazy
[14:32]	:	I saw your email on opensource-dev and thought I needed to answer but was sidetracked by burning issues
[14:32]	:	it needs to go upstream somehow, or you are right there is little point in such a big change
[14:33]	:	second, the question is: how we develop big fundamental stuff that need to live in a half bake stage for a while?
[14:33]	:	if we wait till it's ready, there's no collab
[14:33]	:	feature branches?
[14:33]	:	Aleric, wouldn't it be easier to just put the file chooser in it's own program
[14:33]	:	if we push into trunk, it's unstable
[14:33]	:	I know the answer to that I'd get from Bos and CG
[14:34]	:	:-P
[14:34]	:	starts with h and ends in g?
[14:34]	:	Mercurial branches on bitbucket
[14:34]	:	Does that answer involve "Shrek Ears"?
[14:34]	:	why not?
[14:34]	:	yeah, that's really what it's meant for
[14:34]	:	though it'd help to have trunk on hg, too, for that
[14:35]	:	so, the solution would be for you Aleric to have a bitbucket account and post your Snowglobe modified branch there
[14:35]	:	and tell everyone in opensource-dev: looks, I'm working on this and it's there and you can pull from it
[14:35]	:	i signed up, and they only allow one repos per account
[14:35]	:	Dzonatas: Maybe... but because I did the rest in a general reusable way, that is not really the point. LLAPRMemoryPool, LLReadWriteLock and LLThreadSafe make good additions anyway.
[14:36]	:	only one *private* repo per account
[14:36]	:	it looks like a fork but, really, with solutions like hg and git, everything is a fork
[14:36]	:	oh? so many forks?
[14:36]	:	or rather, forks are non issues
[14:36]	:	no one pushes anywhere, everyone pulls
[14:37]	 	digs for a good article he read on the sibject recently
[14:37]	:	http://hginit.com ?
[14:37]	:	I'd think I'd push to my own private repo
[14:37]	:	but well, using quilt now :p
[14:37]	:	the idea behind a push is so the upstream doesn't get stuck with the job to apply a patch
[14:37]	:	"Forking, The Future of Open Source, and Github": http://monk.ly/9qcE5t
[14:38]	:	Aleric, top-hg?
[14:38]	:	"no one pushes" as in "no one pushes to someone else's repo"
[14:38]	:	a push doesn't mean upstream has to accept into master
[14:38]	:	I tweeted that last week (from Ted Leung)
[14:38]	:	it's really a mindset change
[14:39]	:	it took me a while to turn positive on that but I think I'm warming up to that new idea
[14:39]	:	quilt is pretty kewl...
[14:39]	:	>quilt series | sed -e 's%/usr/src/secondlife/secondlife/snowglobe/quilt/patches/%%;s/.*ku.*/*sensored*/'
VWR-558_threadsafe_gtk_gdk_x11_sdl.diff
[14:39]	:	http://jira.secondlife.com/browse/VWR-12873 
[#VWR-12873] Build error on http-texture branch. "'skip' is not a member of 'tut::test_result'
[14:39]	:	http://jira.secondlife.com/browse/SNOW-553 
[#SNOW-553] C++ API needed to write the IPC part needed for plugins (like client-side scripting, augmented reality, LSL IDE, etc etc)
[14:39]	:	http://jira.secondlife.com/browse/SNOW-593 
[#SNOW-593] An API to wrap objects for thread-safe access.
[14:39]	:	http://jira.secondlife.com/browse/SNOW-596 
[#SNOW-596] APR memory pool used in an error prone way
[14:39]	:	http://jira.secondlife.com/browse/VWR-558 
[#VWR-558] File > Upload or File > Bulk upload disconnects the viewer, if you do not choose the upload files within the first minute
[14:39]	:	http://jira.secondlife.com/browse/SNOW-72 
[#SNOW-72] Fonts are not readable / unacceptably borked
[14:39]	:	http://jira.secondlife.com/browse/VWR-14435 
[#VWR-14435] Invisible Avatar, except attachments, eyes, linden hair, eyelids and shadows.
[14:39]	:	http://jira.secondlife.com/browse/VWR-13486 
[#VWR-13486] Texture rendering fail
[14:39]	:	http://jira.secondlife.com/browse/VWR-14914 
[#VWR-14914] Intermittent FPS drop related to "audio" (main thread hangs often on openal lock)
[14:39]	:	http://jira.secondlife.com/browse/VWR-6199 
[#VWR-6199] Decompile avatar LLM mesh(es) back to their source format
[14:39]	:	speaking about mindset changes ... (maybe a daring idea) ... what if snowglobe becomes upstream for the official viewer, rather than vice versa (as it is now)?
[14:39]	:	lol @ the bots
[14:39]	:	who....chat spam
[14:40]	:	aleric, don't make latif bring LolaBot here
[14:40]	:	Boroondas: that a big change indeed ! :)
[14:40]	:	heheh
[14:40]	:	It was just one "line" ;)
[14:40]	:	but, eventually, that's what we should be doing, like WebKit is to Apple Safari
[14:40]	:	There is Aleric's roadmap.
[14:40]	:	Let LL worry whether they want to diverge from Snowglobe or not ;-)
[14:41]	:	Lindens should eventually contribute to the public repo direct;y
[14:41]	:	Snowglobe as upstream for the official viewer... that seems word of mouth of some lindens =)
[14:41]	:	and "LL official SL viewer" will be our own "TPV" of sort to address what we think is ou main user category
[14:41]	:	:-)
[14:42]	:	that way all internal sources are pulled rather than pushed
[14:42]	:	note that doing something like that begs another "can of worm" question
[14:42]	 	wonders if he'll dare that one...
[14:42]	:	works for Eclipse =)
[14:42]	:	...
[14:42]	:	That would be a great solution, if WE were upstream :)
[14:42]	:	license: GPL is not super friendly to derivative commercial work
[14:43]	:	all commericial/internal development of Eclipse pull from the main
[14:43]	:	GPL 3.0 friendlier... options are Apache and MS-PL
[14:43]	:	if you take WebKit as a model, LGPL would be better
[14:43]	:	ok i've really got to vanish tonight, catch up later if someone saves a chat log
[14:44]	:	well, that's a *huge* change, that would require much better componentization of the code I guess
[14:44]	:	it doesn't mean "we" are upstream... it just means "open source" is upstream
[14:44]	:	LGPL would need componentization???
[14:45]	:	no, not per se
[14:45]	:	Another reason why "snow globe" is a good icon: it's open, lets you look inside :)
[14:46]	:	transparent, not open. If a snowglobe is open the fluid with the glitter will come out.
[14:46]	:	but I can imagine a core being LGPL, the "chrome" for the public SG being "GPL" and a flurry of commercial viewers existing based on the core
[14:46]	:	commercial or not
[14:46]	:	up to them of course
[14:46]	:	I've turned the entire viewer into a shared library... so it is possible
[14:47]	:	The trap with that kind of model (pretty much like opensim, come to think of it) it that you don't make end-user usable software anymore.
[14:47]	:	.... for some reason I feel that a change of license, even another open license, will not be received well...
[14:47]	:	well, that's why you have a GPL chrome
[14:48]	:	so all parts would still be maintained by the snowglobe project, even though differently licenced
[14:48]	:	You'd probably have to dual license it... GPL + something... so anyone can still keep using SG as GPLed.
[14:48]	:	Aleric: rule #1 of FLOSS: any change in license *always* result in a battle...
[14:48]	:	:-P
[14:48]	:	doesn't LGPL allow to relicense as GPL?
[14:48]	:	Dual license: the viewer is already dual licensed
[14:49]	:	not to us
[14:49]	:	Different duo.
[14:49]	:	you can get a commercial license from LL, if you ask them
[14:49]	:	dual license does not mean the code you get has 2 licenses
[14:49]	:	it means you can get it in 2 flavors
[14:50]	:	from the same source (LL in that case)
[14:51]	:	The point is of course... that even though we signed the dev agreement (in order to allow LL defend the GPL in court)... we all contribute to a GPL project in the assumption that our contributions will stay GPL only... If LL needs also under some other licenses internally oh well... but if the whole open source project would switch licenses.. then every contributor would have to agree imho, or it would be imoral to change it.
[14:51]	:	I see your point
[14:51]	:	When/If content becomes self-contained in functionality and security, or any movement towards such, I think the current license issues will depart more
[14:52]	:	as I said, it's a huge can of worm
[14:52]	:	I'm not saying we are planning to do that
[14:52]	:	I was just freely musing on the "let's make SG the upstream" point
[14:53]	:	For what I care it could be WTFPL (that's a real license, btw.), as long as that allows relicencing under GPL.
[14:54]	:	I would not be happy with a BSD license.
[14:54]	 	didn't know about that license but gets the point :)
[14:54]	:	I understand that in order to move SG upstream from current internal development that something like LGPL components are needed. That's probably why we already see some componentization in the viewer already? Speculative answer I'll assume.
[14:55]	:	http://sam.zoy.org/wtfpl/ (more permissive even than BSD)
[14:55]	:	speculative indeed
[14:55]	:	sidenote technical disscussion: Linux SG2 build fails to webkit with this error: WARNING: LLPluginInstance::load: apr_dso_load of /home/brick/games/Snowglobe-i686-2.0.0.0/bin/llplugin/libmedia_plugin_webkit.so failed with error 20019 , additional info string: /home/brick/games/Snowglobe-i686-2.0.0.0/bin/llplugin/libmedia_plugin_webkit.so: undefined symbol: _ZN18LinuxVolumeCatcherD1Ev
[14:55]	:	componentization is also good engineering, especially when you want to move toward "test driven" practices
[14:56]	:	as we do
[14:56]	:	Personally, I've had BSD code and it never went well when people wtf they want with the code.
[14:56]	:	LinuxVolumeCatcher::~LinuxVolumeCatcher()
[14:57]	:	incompletely defined class I bet. Missing virtual function?
[14:57]	:	hmmm.... that's your local build Thickbrick?
[14:57]	:	just tested on your build, merov
[14:57]	:	aaagh...
[14:57]	:	k, guys, I need to run (litterally)
[14:58]	:	I'll look at your issue when back (15 min) Thick brick
[14:58]	:	see you Thursday and sorry to run that abruptly
[14:58]	:	I'll put that in jira, in any case.
[14:58]	:	thanks!
[14:58]	:	cheers
[14:59]	 	worked on software developed in the government under BSD license found in JVM... tooks awhile to get the "father of java" to admit he wasn't the originator
[14:59]	:	heh
[14:59]	:	hu?
[14:59]	:	just sayin'
[15:00]	 	greps for LinuxVolumeCatcher
[15:00]	:	indra/media_plugins/webkit/linux_volume_catcher.h
[15:01]	:	Thickbrick... i get that error also, but it build and compiles.. just gives that error as a run-time link
[15:02]	:	yes, same here, causes webkit to not load.
[15:03]	:	Thx for inviting me to the mtg everybody!! Maybe b4 too long i can actually help! Have fun!
[15:04]	:	welcome =)
 
Generated with SLog Wikifier