Open Source Meeting/2008-01-03
Jump to navigation
Jump to search
Open source meeting - Thursday, 2pm PT.
Teleport to the Linden Open Source Project headquarters.
Agenda
- LLMozLib, its development and future
- Please add items here
...
If there is time left over triage a few bugs?
Transcript
- [14:03] Soft Linden: Oh hey, M2 - the amd64 slviewer deb is a version behind the art deb. The art deb claims a dependency on a matched version
- [14:03] Rob Linden: we'll wait a minute or two to get started, since people are still coming in at a pretty rapid pace
- [14:04] Michelle2 Zenovka: S
- [14:04] Michelle2 Zenovka: Soft, i know, i tried to update to fix the german issue but my main build system is down, i;ve update i386 but amd64 is behind
- [14:04] Soft Linden: kk
- [14:05] Dzonatas Sol: have offered friendship to Michelle2 Zenovka
- [14:06] Rob Linden: alright, so, let's talk about llmozlib
- [14:06] Tofu Linden: Yes, let's! :)
- [14:06] Callum Linden: yay
- [14:06] Michelle2 Zenovka: go for it
- [14:07] Rob Linden: if you were really paying attn
- [14:07] Rob Linden: you would have seen the update today
- [14:07] Michelle2 Zenovka: saw the svn commit of llmozlib
- [14:07] Rob Linden: I haven't announced it onlist yet, but the commit mail went out
- [14:07] Rob Linden: (I also fixed llmozlib commit mails) ;-)
- [14:07] Tofu Linden: Callum Linden's our main llmozlib architect, FYI. I try to keep on top of the Linux porting.
- [14:08] Callum Linden: so, i saw a bunch of questions/points in an email - shall we go through them one by one or do folks have other questions first ?
- [14:08] Michelle2 Zenovka: thinks yea that was me again
- [14:10] Rob Linden: short term solution: I made some scripts to make pushing llmozlib simpler
- [14:10] Rob Linden: that will hopefully mean that I'll be able to do it more frequently than I have
- [14:10] Michelle2 Zenovka: great, that will save me stubbing out new functions as they get added
- [14:11] Rob Linden: as for a medium/long term solution, this /may/ be a good candidate for actually just developing in the public repository
- [14:11] Tofu Linden: I think Callum and myself are keen on that.
- [14:11] Callum Linden: agreed - i'd like to move towards that
- [14:11] Michelle2 Zenovka: Yes i think i suggusted a public repro too
- [14:11] Dzonatas Sol: that would be a very nice step
- [14:11] Michelle2 Zenovka: there is other interest in the library outside secondlife
- [14:12] Rob Linden: the good news here is that it isn't as intertwined with non-releasable stuff as much of oour other code is
- [14:12] Callum Linden: Michelle2: there is a lot
- [14:12] Tofu Linden: I understand Callum has been fielding a lot of non-SL interest in llmozlib - right Callum?
- [14:13] Callum Linden: probably worth mentioning a little bit about the new version we're working on
- [14:13] Tofu Linden: nods.
- [14:13] Callum Linden: (that's true tofu).
- [14:13] Callum Linden: we've moved the dependencies around so that the media lib (LLmedia) is the only thing that depends on LLMozLib - should make it easier to work with - easier to comment out for example
- [14:14] Michelle2 Zenovka: have you made it a shared library yet?
- [14:14] Callum Linden: Michelle2: you mean a DLL in Windows'y term ?
- [14:14] Callum Linden: (s)
- [14:14] Michelle2 Zenovka: yes
- [14:15] Tofu Linden: And there's a new version of llmozlib itself in the works, right Callum? It's been updated to work with more recent mozilla trees and has some functionality/efficiency improvements.
- [14:15] Callum Linden: we haven't - i don't know much about the differences apart from the obvious ones - would that be a big win ?
- [14:15] Callum Linden: Tofu: yep - better updating (dirty rects), uses the latest version of FF code and some other tweaks.
- [14:15] Michelle2 Zenovka: it saves a massive linkage against the viewer, it depends on how you then link to mozilla
- [14:15] Tofu Linden: I can see a win in that apps can share a llmozlib, but they'd have to be sharing the corresponding mozilla tree too.
- [14:16] Soft Linden: It would facilitate dropping another pluggable browser in, and would keep mozlib support from being a build-time dependency.
- [14:16] Michelle2 Zenovka: As you know i don't use the mozilla tree i use xulrunner
- [14:16] Callum Linden: yep - that means you don't get the patched code though - some things must be broken i expect ?
- [14:16] Tofu Linden: Yeah Michelle2, kudos for getting that to work, but I don't know if that will continue to do so.
- [14:17] Michelle2 Zenovka: Hmm, its a bit of an issue if it breaks. But hopefully by the time firefox 3 goes live xulruner will build firefox itsself
- [14:17] Rob Linden: for Callum's benefit: Michelle2==Robin Cornelius on sldev mailing list. Michelle2 is working on a Second Life Viewer Debian package
- [14:17] Tofu Linden: Off the top of my head I expect that to mildly break some widgets in llmozlib1, but it'll also break dirty-rect updating in llmozlib2 which is more serious.
- [14:17] Callum Linden: AFAIUI, the Firefox3 code (Gecko 1.9) is going to break everything
- [14:18] Callum Linden: Tofu: that's what i was thinking too
- [14:18] Michelle2 Zenovka: right this could be a serious issue for debian inclusion
- [14:19] Callum Linden: Michelle2: now that (eventually) LLMozLib is only linked to by LLMedia which itself it quite small - does that help with linkage issues ?
- [14:19] Dzonatas Sol: Are we thinking of llmozlib being in its own deb?
- [14:20] Michelle2 Zenovka: Callum, as llmolbiz carries its own mozilla it makeds the slviewer binary massive
- [14:20] Tofu Linden: I believe the llmedia isolation will make the viewer much much less prone to random bustage when llmozlib is totally disabled, but I'm not sure I see it helping otherwise.
- [14:20] Callum Linden: understood (both).
- [14:20] Michelle2 Zenovka: Dz, currently i have llmozlib in its own deb
- [14:21] Callum Linden: if we could live without the dirty rect updating (like it is now in the current client) and some broken widgets, we could link against a local version then - i don't think that helps on Windows though - might on Mac.
- [14:21] Rob Linden: another thing the llmedia work does is makes alternative html implementations easier
- [14:21] Michelle2 Zenovka: No dosn't help windows, i could not get it to work there with xulrunner
- [14:22] Callum Linden: understood Michelle2
- [14:22] Tofu Linden: Correct me if I'm wrong, but we have no particular fondness for using a patched mozilla - we'd be using a mainstream mozilla if we could, but we're doing things with mozilla that it wasn't really meant for out-of-the-box.
- [14:23] Callum Linden: Tofu: exactly.
- [14:23] Michelle2 Zenovka: Yes Tofu, the only way to do this with mozilla is to use internal API which is not exposed in the mozilla components though which is why you need to build and extract from a mozilla tree
- [14:23] Prospero Linden: yikes
- [14:23] Dzonatas Sol: Tofu, that happens more often now. so perhaps firefox 4 would address it if the issues is raised somehow
- [14:24] Tofu Linden: Rob's point about alternative HTML renderer implementations is a great one, though I understand that people can slot-in alternative browser implementations under llmozlib as effectively as they can under llmedia.
- [14:25] Saxet Uralia: waves hello
- [14:25] Michelle2 Zenovka: Hmm, if llmozlib supports alternitive html implementations then this could be the solution, i just package an approprate alternitive if necessary?
- [14:25] Squirrel Wood: any chance to recognise an installed firefox version and utilize the installed add-ons/plugins of that one? Like, AdBlock, Flashblock, Noscript, ... ?
- [14:25] Callum Linden: yep, that's right - each media type has a different impl - it's quite easy to switch out LLMozLib for example and use something else - finding the something else is the interesting part :) i think i know how to do it with IE but not sure how useful that will be :)
- [14:25] Tofu Linden: khtml, webkit, or whatever - though, y'know, those implementations don't actually exist in practise yet. :
- [14:26] Tofu Linden: :)
- [14:26] Rob Linden: would LOVE to see a proof of concept of webkit
- [14:26] Callum Linden: Squirrel: what Michelle2 said - it uses interfaces not-present in installed apps like FF
- [14:26] Tofu Linden: squirrel: Not a huge chance I believe, most of these add-ons interface at the mozilla chrome level, and we don't use the mozilla chrome.
- [14:27] Squirrel Wood: k
- [14:27] Michelle2 Zenovka: In theory you could steal some of the components but you need other stuff not usualy exposed by firefox but is exposed by mozilla (except profdirserviceprovide which even i had to steal from a mozilla tree)
- [14:27] Michelle2 Zenovka: *not mozilla xulrunner
- [14:28] Callum Linden: Michelle2: yes, you should be able to - FWIW, we've been calling this new version LLMozLib2
- [14:28] Callum Linden: Michelle2: yes, I think so.
- [14:29] Callum Linden: shall we talk about the other points in the email - version numbering for example great idea
- [14:29] Michelle2 Zenovka: yes please do
- [14:29] Callum Linden: based on date? number od days since first build? something else ?
- [14:29] Soft Linden: If it goes to the secondlife.com svn, revision number is most useful imho
- [14:29] Michelle2 Zenovka: can you use a release version liek you do with the viewer and development builds can be 1.2.3.todaysdate or 1.2.3.svncommi number
- [14:30] Tofu Linden: As well as technical changes, llmozlib2 is important in finally unifying the codebase, which finally undoes the semi-fork which the LL version and the ubrowser.com versions took.
- [14:30] Callum Linden: yep Tofu - if we can move this to external SVN entirely, that will complete the unification.
- [14:31] Callum Linden: Michelle2: okay, i'll make a note and create a task for it.
- [14:31] Callum Linden: next point - cmake - not sure about this since i haven't been involved with the cmake effort - anyone else know ?
- [14:31] Michelle2 Zenovka: cool
- [14:32] Tofu Linden: Sorry, what was the cmake question?
- [14:32] Tofu Linden: goes to look
- [14:32] Callum Linden: Tofu: Are you going to use cmake for llmozlib,
- [14:32] Michelle2 Zenovka: Well we need a build environment, Rob suggusted cmake as its in fashion (at a previous meeting)
- [14:32] Tofu Linden: Oh, right.
- [14:32] Callum Linden: can't think of a good reason not to - sounds like it's a good solution - i sit next to Bos :)
- [14:32] Michelle2 Zenovka: i have already done an autotools build for linux and its on a JIRA somewhere
- [14:33] Callum Linden: michelle2: will cmake work for you ?
- [14:33] Tofu Linden: cmake would make sense. at the moment it's some silly helper-scripts.
- [14:33] Michelle2 Zenovka: but if you are cmaking everyhing then might as well keep it consistent
- [14:33] Callum Linden: ok - good - let's do it then
- [14:34] Michelle2 Zenovka: cmake can make a linux makefile, but i may end up having to change it anyway to build my way but i will not know untill i see it and llmozlib2 :-)
- [14:34] Callum Linden: next point was shared library - we've covered this a bit
- [14:34] Tofu Linden: We're still getting cmake going for the SL viewer, it's looking really positive though IMHO.
- [14:35] Tofu Linden: So when cmake is 'proven' for the viewer, I think would be the time to work the same magic on llmozlib.
- [14:35] Callum Linden: agreed - i'll add that to the list
- [14:36] Tofu Linden: The shared library question is more a philosophical one than the technical one. It's easy enough to make a .so, but we need a policy on numbering - and that's if it even makes sense given a dependancy on a fairly specific moz tree build.
- [14:36] Dzonatas Sol: for dso's, i suggest a version and uuid method of tagging files
- [14:37] Dzonatas Sol: version is traditional, and uuid is for updating against builds
- [14:37] Callum Linden: i'll defer to tofu for linux'y questions :)
- [14:37] Michelle2 Zenovka: What you don't want is the traditional windows issue of lots of dlls with the same name all different versions an dno idea which ones which
- [14:38] Michelle2 Zenovka: as for shared/static, it is trival to switch
- [14:39] Tofu Linden: All agreed, we won't keep calling every llmozlib version libllmozlib.a forever. :)
- [14:39] Wyn Galbraith: sorries but has to run. "See y'll later gators."
- [14:39] Tofu Linden: Bye Wyn.
- [14:39] Michelle2 Zenovka: or have it report version 1.1.1 in the version string :-)
- [14:39] Callum Linden: ok, sounds like we need a longer disussion on this later
- [14:39] Jason Swain: See you Wyn
- [14:39] Rob Linden: callum times out in a little bit, so we should make sure we quickly nit on the points we need him for
- [14:39] Soft Linden: This discussion makes more sense after llmozilb when - presumably the interface will be more static?
- [14:39] Soft Linden: llmozlib2 rather
- [14:40] Callum Linden: Soft: true , good point
- [14:40] Callum Linden: next point was bug tracker - if LLmozLib/LLmozLib2 exist only in the public SVN, what should be use to track bugs?
- [14:41] Tofu Linden: (Soft - given our sort of ad-hoc interface additions historically, I'm not sure how static the interface is really going to be - I think as llmozlib goes 'indie', we'll have to be a lot more thoughtful about interface changes.)
- [14:41] Rob Linden: we can potentially create a new project in jira.secondlife.com, or just a component of viewer
- [14:41] Tofu Linden: A new project sounds pretty good to me.
- [14:41] Soft Linden: Can we do something about JIRA-oriented signups?
- [14:41] Rob Linden: that's one I can resolve in a bit
- [14:42] Callum Linden: sounds good rob - seems o me like it makes sense to keep it all in the samle "location"
- [14:42] Tofu Linden: 'jira-oriented signups'?
- [14:42] Michelle2 Zenovka: makes sense if you are managing it
- [14:42] Soft Linden: Like a JIRA-only registration flow so people aren't choosing gender and furry/human, etc just to report a bug for a non-SL mozlib project.
- [14:42] Callum Linden: ok, lastly, ubrowser - hasn't changed much - not much more to add :) it's really just a test platform and not a real browser.
- [14:42] Rob Linden: interesting point soft....I want to table that though to make sure there's nothing else for Callum
- [14:42] xDIMITRIHILLS: coute: TRADUIRE sur le canal /0
- [14:42] DIMITRIHILLS Criss: salut ca va
- [14:42] xDIMITRIHILLS: hello: Ca goes
- [14:42] Tofu Linden: Soft - great point.
- [14:43] Callum Linden: (sorry soft - didn't notice you were typing)
- [14:43] SignpostMarv Martin: has been encouraging volunteers to use the in-world help browser with his alert request system
- [14:43] SignpostMarv Martin: it's quite functional :-P
- [14:43] Dzonatas Sol: we need the 'bug' avi
- [14:43] Dzonatas Sol: =)
- [14:44] Callum Linden: forgive me everyone, i had some bad news yesterday and have to leave for asia in a few hours - i'd love to stay longer but i have to get ready - i'd like to start office hours when i get back - would that be useful do you think ?
- [14:44] Dzonatas Sol: thank for your time here
- [14:44] Callum Linden: not at all - i've been wanting to do this for ages. thanks for all your input
- [14:44] Rob Linden: thanks Callum!
- [14:45] Jason Swain: I hope all goes as well as it can for you Callum, Thank you again
- [14:45] Tofu Linden: Cheers Callum.
- [14:45] Michelle2 Zenovka: sounds good, i often can't make office hours its an idea, yea thanks callum
- [14:45] Callum Linden: ok, sorry again i have to tun off - maybe it's best just to keep coming to these meetings - i';ll be at the next one when i et back.
- [14:45] Rob Linden: by all means
- [14:45] Callum Linden: thanks everyone - see you soon.
- [14:46] Michelle2 Zenovka: Bye, take care
- [14:46] Rob Linden: k....back to Soft's point: logging into JIRA requires an SL signup, but there may be people who aren't otherwise interested in SL who want to use llmozlib
- [14:47] Tofu Linden: nods!
- [14:47] Q Linden: similarly for eventlet
- [14:47] Rob Linden: I don't have a simple answer for that unfortunately
- [14:47] SignpostMarv Martin: is there any version of the JIRA software that supports OpenID logins ?
- [14:48] Dzonatas Sol: If llmozlib is kept in external svn under gpl (or like) then the free version of jira can be used, being could be made ran separate from the one that exists now
- [14:48] Dzonatas Sol: (just a thought)
- [14:48] Soft Linden: I'm thinking a separate regflow with a bogus estate ID and a fixed lastname like BugReporter that's prefilled if they select "non-SL account"
- [14:48] SignpostMarv Martin: adding OpenID login support tothe JIRA would allow people to log into the JIRA without needing an SL account
- [14:48] Soft Linden: It should be easy to set up a bare-bones one-page registration for that.
- [14:48] Baba Yamamoto: perhaps an expediated SL sign up which skips all the details... sort of "Oh yea, you can also use this account to sign into Second Life" heh
- [14:49] Rob Linden: well, there's the mechanics, and then there's the policy
- [14:49] SignpostMarv Martin: googles
- [14:49] Dzonatas Sol: the OpenID option sounds good also
- [14:49] Rob Linden: the whole point of tying into the SL database is to have one user database to manage, not two
- [14:49] Dzonatas Sol: but would need brokers
- [14:50] SignpostMarv Martin: [1]
- [14:50] Rob Linden: ...so that when someone violates policy (blatent griefing, whatever), we nuke their access from all of our systems, rather than have them hop from system to system
- [14:50] Baba Yamamoto: Rob, how's that working for you?
- [14:50] Baba Yamamoto: i mean the blocking of offenders ;)
- [14:51] SignpostMarv Martin: Rob: you could just as easily create SL account after SL account viathe RegAPI
- [14:51] Michelle2 Zenovka: Could they create a new account with a "flag" that prevent sthe account loggin in to SL or other ares untill they have given all details and ticked all boxes as per standard free SL account signup?
- [14:51] SignpostMarv Martin: forcing people to create Second Life accounts seems rather pointless
- [14:51] Baba Yamamoto: that sounds interesting
- [14:52] Michelle2 Zenovka: i mean a really basic username/password on the same database but therefor restricted as its not complete ingo
- [14:52] Michelle2 Zenovka: *info
- [14:52] Soft Linden: Alternate option - if JIRA supports anonymous users, could we turn that on, but restrict them to something like an "Untriaged" project, and move in whatever is meaningful?
- [14:52] Rob Linden: really, really doesn't want a separate user database
- [14:53] SignpostMarv Martin: create a nerfed account in order to log into a 3rd party piece of software to participate in the development of open source software.....
- [14:53] SignpostMarv Martin: that sounds totally fucked up to be honest
- [14:53] Soft Linden: SignPost++
- [14:53] Soft Linden: Still, what's the solution here without upending the whole issue tracker?
- [14:53] SignpostMarv Martin: either create a seperate JIRA, or add OpenID support
- [14:54] Rob Linden: so, do we have specific examples of people that have had problems, or is this a general concern?
- [14:54] Squirrel Wood: Option: Standard SL account setup, just add a hidden field 'Jira access only' to it ?
- [14:54] SignpostMarv Martin: of course, if you create a seperate JIRA and added OpenID support to that, you could use SLOpenID.net to log in as an SL Resident :-P
- [14:55] Rob Linden: thinks we're trying to solve a problem that shouldn't be at the top of the list
- [14:55] Soft Linden: Yeah, or at least should go to the mailing list for more thought-out discussion.
- [14:55] Soft Linden: I think we're brainstorming in realtime without needing to.
- [14:56] Michelle2 Zenovka: Agreed, its a complex issue
- [14:56] Rob Linden: if this was the most important problem I had to solve right now, I'd be SOOO happy :)
- [14:56] Dzonatas Sol: has the log so no worries there =)
- [14:57] Rob Linden: anyway, anything else we should cover? I'm booked for 3pm, so I'll have to leave right at the end
- [14:57] Baba Yamamoto: Has there been any progress on cleaning up Jira? there was quite a bit of issue rot going on as of last month
- [14:57] SignpostMarv Martin: could bring up his rewrite of LL's webmap API :-P
- [14:58] Rob Linden: Baba: some process changes at LL that should be kicking in this month
- [14:58] Baba Yamamoto: gigs finally got his jira stats/browser webapp going
- [14:58] Rob Linden: holidays were brutal for us, because we took vacation, and residents didn't :)
- [14:58] Baba Yamamoto: Muahahaha
- [14:59] Baba Yamamoto: Rob, can you enlighten us as to the policy going into effect?
- [14:59] Rob Linden: entire QA team should be getting more involved in the triage process
- [14:59] Baba Yamamoto: good
- [15:00] Squirrel Wood: Yay!
- [15:00] Rob Linden: anyway, gotta go
- [15:00] Baba Yamamoto: see ya
- [15:00] Rob Linden: thanks everyone for comign!