Open Source Meeting/2010-04-13

From Second Life Wiki
Jump to navigation Jump to search

Transcript

[14:06] Ardy Lay: Well, I am not gonna distribute anything. I might contribute trivial patches via pJIRA, that all.
[14:06] Ardy Lay: So here I am.
[14:06] Michelle2 Zenovka: Looks like that rounded up a few
[14:06] Dzonatas Sol: =)
[14:06] Merov Linden: hey
[14:07] Merov Linden: ok, well, I didn't prepare an agenda
[14:07] Merov Linden: SG2.0 trunk did build on all platfroms yesterday night!
[14:07] Merov Linden: W00t!!
[14:07] Dzonatas Sol: woot
[14:07] Thickbrick Sleaford: nice
[14:07] Merov Linden: thanks a lot to Thickbrick and Techwolf
[14:08] Aleric Inglewood: ... I was kayaking!
[14:08] Thickbrick Sleaford: Mainly Techwolf...
[14:08] Merov Linden: the remaining problems now are:
[14:08] Merov Linden: 1) it doesn't send an email with the links to the produced binaries
[14:08] Dzonatas Sol: update libuuid =)
[14:08] ATechwolf Foxclaw: I'me here....but text only.
[14:09] Merov Linden: 2) the names of the packages for Linux is not correct
[14:09] Merov Linden: I also wanted to take the "SNOWGLOBETESTBUILD" suffix added to the Mac version
[14:09] Merov Linden: does someone remember?
[14:09] Merov Linden: I don't remember why we added that...
[14:10] Merov Linden: o, thanks lag for inversing my sentences in chat...
[14:10] ATechwolf Foxclaw: I never got a notice in IRC that the build passed. ie:not failed.
[14:10] ATechwolf Foxclaw: So my patch worked and I found out today.
[14:11] Merov Linden: yes ATechwolf, that's what I said...
[14:11] ATechwolf Foxclaw: Sorry, I got here late.
[14:11] Merov Linden: I know it passes because I can see the result logs and S3 place filled
[14:11] ATechwolf Foxclaw: Do we have access to that log?
[14:11] Merov Linden: the email didn't get sent though
[14:12] ATechwolf Foxclaw: One question I have, why is parabuild doing debug, releasedebug before the release that is packaged?
[14:12] Merov Linden: I can make and email "manually" giving all that
[14:12] Dzonatas Sol: 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] JIRA Helper: 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] ATechwolf Foxclaw: I found the mailing list on the web and was looking at the failed builds and noticed that.
[14:13] Merov Linden: ATechwolf: I don't know the reason of doing debug and relnodebug...
[14:13] Merov Linden: we're not posting the result of those
[14:13] ATechwolf Foxclaw: I'me folling two convoes, sorry for any delay.
[14:14] Merov Linden: hmmm... may be to ensure it builds in those 2 situations?
[14:14] Thickbrick Sleaford: Ha, got the build log: http://s3.amazonaws.com/viewer-source-downloads/2010/trunk/3318/good-build.Linux
[14:14] ATechwolf Foxclaw: yea :-)
[14:14] Thickbrick Sleaford: (byt guessing url)
[14:14] Merov Linden: good one Thickbrick
[14:14] Merov Linden: :)
[14:14] Merov Linden: not a secret for sure
[14:14] Aleric Inglewood: Did you get 1.4 to build Merov?
[14:14] Merov Linden: and now, accessible for all :)
[14:15] Merov Linden: Aleric: good question and the answer is "no"
[14:15] Merov Linden: let me tell you the reason
[14:15] Merov Linden: we need the 1.23 bundles (the asset stuff) to build 1.4
[14:15] ATechwolf Foxclaw: I'me trying to move to the seats....if I run over somebody, sorry.
[14:15] Merov Linden: well, it just happen that those bundles on S3 are "cleaned" after 3 months
[14:16] Merov Linden: so we lost the old ones... :(
[14:16] Thickbrick Sleaford: Techwolf, you're colliding with a signpost
[14:16] Aleric Inglewood: So much for keeping supporting 1.23 and SG 1.x for another few years.
[14:16] Merov Linden: 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] Merov Linden: so I've been trying to fix that with CG
[14:17] Merov Linden: we passed build but have a problem with export
[14:17] Merov Linden: don't say "so much for", we are working to fix the problem
[14:18] Merov Linden: I and CG I mean
[14:18] Merov Linden: seriously
[14:18] Merov Linden: I really hope to be done with that shortly
[14:19] Merov Linden: once we get the 1.x export working again, I'll merge with SG 1.4 and build
[14:19] Merov Linden: I basically spend most of my days doing fix and launching parabuild tasks these days... :/
[14:20] Merov Linden: not fun... but necessary
[14:20] Aleric Inglewood: I have a question :)
[14:20] Merov Linden listens
[14:20] ATechwolf Foxclaw: Can you add "time" to that build? I'me courious on the build times. :-)
[14:21] Merov Linden: You mean: in the log ?
[14:21] Aleric Inglewood: 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] ATechwolf Foxclaw: Yea. More of coursity then anything else.
[14:22] Aleric Inglewood: 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] Merov Linden: ATechwolf: we have that info (displayed in Parabuild) so I suppose we can output it
[14:22] Merov Linden: in the log
[14:23] Merov Linden: Aleric: the issue is about changes in SG that would never find their way in the main viewer
[14:24] Merov Linden: it's certainly an issue for some feature (VWRAP may be, though even that could be in the main viewer IMO)
[14:24] Merov Linden: 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] Merov Linden: perf improvements, rendering improvements, etc...
[14:25] Aleric Inglewood: 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] Merov Linden: 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] Dzonatas Sol: plugins
[14:26] Merov Linden: I think this is something we (the Snowglobe contributors) should decide collectively
[14:26] Boroondas Gupte: 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] Merov Linden: like: "yes, this feature is essential for any viewer, lets start here and push it"
[14:27] Merov Linden: or "no, this feature is interesting for some markets but not really mainstream, it should live in its own TPV"
[14:27] Thickbrick Sleaford: 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] Boroondas Gupte: hmm, true
[14:28] Merov Linden thinks about that for a sec...
[14:28] Dzonatas Sol: experimental, yet some standard is needed
[14:29] Merov Linden: in the big picture, I would like to see Snowglobe the code base for all TPV really
[14:29] Merov Linden: the one that every TPV uses to rebase from
[14:30] ATechwolf Foxclaw: 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] Merov Linden: I don't believe in a one size fit all viewer for all needs on the planet
[14:30] Merov Linden: but a good common base will help everyone
[14:30] Aleric Inglewood: 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] Merov Linden: that's what I'd like to make happen with Snowglobe
[14:31] ATechwolf Foxclaw just got drowned out by Aleric. :-)
[14:31] Aleric Inglewood: 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] Aleric Inglewood: but I don't feel like merging all this EVERY time....
[14:31] Michelle2 Zenovka: 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] Merov Linden: well, first, I think we *need* that refactor in our code :)
[14:31] Aleric Inglewood: If it doesn't go into the main viewer... then I don't want to continue to maintain it
[14:32] Michelle2 Zenovka: maintaining big changes like that permanently is crazy
[14:32] Merov Linden: I saw your email on opensource-dev and thought I needed to answer but was sidetracked by burning issues
[14:32] Michelle2 Zenovka: it needs to go upstream somehow, or you are right there is little point in such a big change
[14:33] Merov Linden: second, the question is: how we develop big fundamental stuff that need to live in a half bake stage for a while?
[14:33] Merov Linden: if we wait till it's ready, there's no collab
[14:33] Boroondas Gupte: feature branches?
[14:33] Dzonatas Sol: Aleric, wouldn't it be easier to just put the file chooser in it's own program
[14:33] Merov Linden: if we push into trunk, it's unstable
[14:33] Merov Linden: I know the answer to that I'd get from Bos and CG
[14:34] Boroondas Gupte: :-P
[14:34] Thickbrick Sleaford: starts with h and ends in g?
[14:34] Merov Linden: Mercurial branches on bitbucket
[14:34] Ardy Lay: Does that answer involve "Shrek Ears"?
[14:34] Boroondas Gupte: why not?
[14:34] Merov Linden: yeah, that's really what it's meant for
[14:34] Boroondas Gupte: though it'd help to have trunk on hg, too, for that
[14:35] Merov Linden: so, the solution would be for you Aleric to have a bitbucket account and post your Snowglobe modified branch there
[14:35] Merov Linden: and tell everyone in opensource-dev: looks, I'm working on this and it's there and you can pull from it
[14:35] Dzonatas Sol: i signed up, and they only allow one repos per account
[14:35] Aleric Inglewood: 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] Thickbrick Sleaford: only one *private* repo per account
[14:36] Merov Linden: it looks like a fork but, really, with solutions like hg and git, everything is a fork
[14:36] Dzonatas Sol: oh? so many forks?
[14:36] Merov Linden: or rather, forks are non issues
[14:36] Merov Linden: no one pushes anywhere, everyone pulls
[14:37] Merov Linden digs for a good article he read on the sibject recently
[14:37] Thickbrick Sleaford: http://hginit.com  ?
[14:37] Aleric Inglewood: I'd think I'd push to my own private repo
[14:37] Aleric Inglewood: but well, using quilt now :p
[14:37] Dzonatas Sol: the idea behind a push is so the upstream doesn't get stuck with the job to apply a patch
[14:37] Merov Linden: "Forking, The Future of Open Source, and Github": http://monk.ly/9qcE5t
[14:38] Michelle2 Zenovka: Aleric, top-hg?
[14:38] Boroondas Gupte: "no one pushes" as in "no one pushes to someone else's repo"
[14:38] Dzonatas Sol: a push doesn't mean upstream has to accept into master
[14:38] Merov Linden: I tweeted that last week (from Ted Leung)
[14:38] Merov Linden: it's really a mindset change
[14:39] Merov Linden: it took me a while to turn positive on that but I think I'm warming up to that new idea
[14:39] Aleric Inglewood: quilt is pretty kewl...
[14:39] Aleric Inglewood: >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] JIRA Helper: 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] JIRA Helper: 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] JIRA Helper: http://jira.secondlife.com/browse/SNOW-593

[#SNOW-593] An API to wrap objects for thread-safe access.

[14:39] JIRA Helper: http://jira.secondlife.com/browse/SNOW-596

[#SNOW-596] APR memory pool used in an error prone way

[14:39] JIRA Helper: 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] JIRA Helper: http://jira.secondlife.com/browse/SNOW-72

[#SNOW-72] Fonts are not readable / unacceptably borked

[14:39] JIRA Helper: http://jira.secondlife.com/browse/VWR-14435

[#VWR-14435] Invisible Avatar, except attachments, eyes, linden hair, eyelids and shadows.

[14:39] JIRA Helper: http://jira.secondlife.com/browse/VWR-13486

[#VWR-13486] Texture rendering fail

[14:39] JIRA Helper: http://jira.secondlife.com/browse/VWR-14914

[#VWR-14914] Intermittent FPS drop related to "audio" (main thread hangs often on openal lock)

[14:39] JIRA Helper: http://jira.secondlife.com/browse/VWR-6199

[#VWR-6199] Decompile avatar LLM mesh(es) back to their source format

[14:39] Boroondas Gupte: 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] Aleric Inglewood: lol @ the bots
[14:39] ATechwolf Foxclaw: who....chat spam
[14:40] Thickbrick Sleaford: aleric, don't make latif bring LolaBot here
[14:40] Merov Linden: Boroondas: that a big change indeed ! :)
[14:40] Aleric Inglewood: heheh
[14:40] Aleric Inglewood: It was just one "line" ;)
[14:40] Merov Linden: but, eventually, that's what we should be doing, like WebKit is to Apple Safari
[14:40] Ardy Lay: There is Aleric's roadmap.
[14:40] Boroondas Gupte: Let LL worry whether they want to diverge from Snowglobe or not ;-)
[14:41] Merov Linden: Lindens should eventually contribute to the public repo direct;y
[14:41] Dzonatas Sol: Snowglobe as upstream for the official viewer... that seems word of mouth of some lindens =)
[14:41] Merov Linden: and "LL official SL viewer" will be our own "TPV" of sort to address what we think is ou main user category
[14:41] Boroondas Gupte: :-)
[14:42] Dzonatas Sol: that way all internal sources are pulled rather than pushed
[14:42] Merov Linden: note that doing something like that begs another "can of worm" question
[14:42] Merov Linden wonders if he'll dare that one...
[14:42] Dzonatas Sol: works for Eclipse =)
[14:42] Boroondas Gupte: ...
[14:42] Aleric Inglewood: That would be a great solution, if WE were upstream :)
[14:42] Merov Linden: license: GPL is not super friendly to derivative commercial work
[14:43] Dzonatas Sol: all commericial/internal development of Eclipse pull from the main
[14:43] Dzonatas Sol: GPL 3.0 friendlier... options are Apache and MS-PL
[14:43] Merov Linden: if you take WebKit as a model, LGPL would be better
[14:43] Michelle2 Zenovka: ok i've really got to vanish tonight, catch up later if someone saves a chat log
[14:44] Merov Linden: well, that's a *huge* change, that would require much better componentization of the code I guess
[14:44] Dzonatas Sol: it doesn't mean "we" are upstream... it just means "open source" is upstream
[14:44] Boroondas Gupte: LGPL would need componentization???
[14:45] Merov Linden: no, not per se
[14:45] Aleric Inglewood: Another reason why "snow globe" is a good icon: it's open, lets you look inside :)
[14:46] Boroondas Gupte: transparent, not open. If a snowglobe is open the fluid with the glitter will come out.
[14:46] Merov Linden: 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] Merov Linden: commercial or not
[14:46] Merov Linden: up to them of course
[14:46] Dzonatas Sol: I've turned the entire viewer into a shared library... so it is possible
[14:47] Thickbrick Sleaford: 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] Aleric Inglewood: .... for some reason I feel that a change of license, even another open license, will not be received well...
[14:47] Merov Linden: well, that's why you have a GPL chrome
[14:48] Boroondas Gupte: so all parts would still be maintained by the snowglobe project, even though differently licenced
[14:48] Aleric Inglewood: You'd probably have to dual license it... GPL + something... so anyone can still keep using SG as GPLed.
[14:48] Merov Linden: Aleric: rule #1 of FLOSS: any change in license *always* result in a battle...
[14:48] Boroondas Gupte: :-P
[14:48] Boroondas Gupte: doesn't LGPL allow to relicense as GPL?
[14:48] Merov Linden: Dual license: the viewer is already dual licensed
[14:49] Boroondas Gupte: not to us
[14:49] Thickbrick Sleaford: Different duo.
[14:49] Merov Linden: you can get a commercial license from LL, if you ask them
[14:49] Merov Linden: dual license does not mean the code you get has 2 licenses
[14:49] Merov Linden: it means you can get it in 2 flavors
[14:50] Merov Linden: from the same source (LL in that case)
[14:51] Aleric Inglewood: 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] Merov Linden: I see your point
[14:51] Dzonatas Sol: 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] Merov Linden: as I said, it's a huge can of worm
[14:52] Merov Linden: I'm not saying we are planning to do that
[14:52] Merov Linden: I was just freely musing on the "let's make SG the upstream" point
[14:53] Boroondas Gupte: For what I care it could be WTFPL (that's a real license, btw.), as long as that allows relicencing under GPL.
[14:54] Aleric Inglewood: I would not be happy with a BSD license.
[14:54] Merov Linden didn't know about that license but gets the point :)
[14:54] Dzonatas Sol: 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] Boroondas Gupte: http://sam.zoy.org/wtfpl/ (more permissive even than BSD)
[14:55] Merov Linden: speculative indeed
[14:55] Thickbrick Sleaford: 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] Merov Linden: componentization is also good engineering, especially when you want to move toward "test driven" practices
[14:56] Merov Linden: as we do
[14:56] Dzonatas Sol: Personally, I've had BSD code and it never went well when people wtf they want with the code.
[14:56] Aleric Inglewood: LinuxVolumeCatcher::~LinuxVolumeCatcher()
[14:57] Aleric Inglewood: incompletely defined class I bet. Missing virtual function?
[14:57] Merov Linden: hmmm.... that's your local build Thickbrick?
[14:57] Thickbrick Sleaford: just tested on your build, merov
[14:57] Merov Linden: aaagh...
[14:57] Merov Linden: k, guys, I need to run (litterally)
[14:58] Merov Linden: I'll look at your issue when back (15 min) Thick brick
[14:58] Merov Linden: see you Thursday and sorry to run that abruptly
[14:58] Thickbrick Sleaford: I'll put that in jira, in any case.
[14:58] Merov Linden: thanks!
[14:58] Merov Linden: cheers
[14:59] Dzonatas Sol 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] Thickbrick Sleaford: heh
[14:59] Boroondas Gupte: hu?
[14:59] Dzonatas Sol: just sayin'
[15:00] Thickbrick Sleaford greps for LinuxVolumeCatcher
[15:00] Thickbrick Sleaford: indra/media_plugins/webkit/linux_volume_catcher.h
[15:01] Dzonatas Sol: Thickbrick... i get that error also, but it build and compiles.. just gives that error as a run-time link
[15:02] Thickbrick Sleaford: yes, same here, causes webkit to not load.
[15:03] Aklo Modan: Thx for inviting me to the mtg everybody!! Maybe b4 too long i can actually help! Have fun!
[15:04] Dzonatas Sol: welcome =)

Generated with SLog Wikifier