User:Oz Linden/Office Hours Archive 2010-09-15

From Second Life Wiki
Jump to navigation Jump to search

List of Attendees

Transcript

[13:02] Boroondas Gupte: hi Robin
[13:02] Robin Cornelius: Hey everyone
[13:03] Robin Cornelius: everyone still at Nyx's?
[13:03] Oz Linden: many, I suspect - was mobbed
[13:04] Latif Khalifa: hello
[13:04] Boroondas Gupte: heya
[13:04] Yuzuru Jewell: Hello.
[13:05] Yuzuru Jewell: Nyx Linden says about mesh on his office hour..
[13:05] Latif Khalifa: i was over there, it's over
[13:06] Boroondas Gupte: brb
[13:09] Boroondas Gupte: back
[13:09] Latif Khalifa: wb Bor
[13:09] Latif Khalifa: what did you do to Oz :P
[13:09] Oz Linden: Boroondas provided us a link to build issues
[13:09] Oz Linden: https://lists.secondlife.com/pipermail/opensource-dev/2010-August/003112.html
[13:09] Oz Linden: what did I do?
[13:10] Oz Linden: I'd like to better understand this list, since the new build framework is coming out soon...
[13:11] Oz Linden: maybe I should describe that?
[13:11] Boroondas Gupte: please do
[13:12] Oz Linden: Briefly... there's a new tool called 'autobuild' that will the top level command you'll exec. It's python, and should work anywhere
[13:12] Oz Linden: to build something with it, you give it a top level description file
[13:13] Oz Linden: that file declares dependencies (among other things)
[13:13] Morgaine Dinova: I thought we were moving away from special build scripts. That was the whole point of changing to cmake.
[13:13] Boroondas Gupte: will that replace CMake or work on top of it?
[13:13] Oz Linden: and for each dependency, autobuild can either do the build (if you have or can download the source), or fetch a prebuilt library
[13:14] Oz Linden: it works on top of cmake
[13:14] Oz Linden: it replaces the develop.py
[13:14] Oz Linden: in a much more general way
[13:14] Boroondas Gupte: does develop.py do anything nowadays? I've been using cmake directly lately.
[13:15] Oz Linden: There's an internal team that's been working through getting builds of all the viewer dependencies that use it
[13:15] Oz Linden: let's not go into develop.py....
[13:16] Oz Linden: they've also just about got the viewer itself building with autobuild, using those dependencies
[13:17] Oz Linden: the plan is to check the autobuild support files into viewer-development soon (probably during the current sprint), and start using it for all builds
[13:17] Morgaine Dinova: This new script is just for prebuilt lib fetching, right? So it has no place in a standalone build?
[13:17] Oz Linden: no, it does the equivalent of a 'standalone' build too - if you have the sources you can use them
[13:17] Boroondas Gupte: it can also fetch lib sources and build those, if I understood correctly
[13:18] Oz Linden: so you set up parallel trees (actually, they can be anywhere, but if they are peers then autobuild can find them automatically)
[13:18] Boroondas Gupte: but what about libs that are installed into the system? standalone currently uses those. Is that still supported, too?
[13:18] Oz Linden: right, Boroondas, if the sources are available, it can
[13:19] Robin Cornelius: sources?
[13:19] Boroondas Gupte: what if only headers and shared object files are installed?
[13:19] Robin Cornelius: thats not a standalone build and will cause a headache for my packaging
[13:19] Morgaine Dinova: At the moment we have a situation where standalone build is clean, and prebuilt is a mess. Now they're both going to be a mess?
[13:20] Ardy Lay: Prebuilt works great for me.
[13:20] Tillie Ariantho: And I'd like to build with VC2010, not 2008 or 2005. ;)
[13:20] Oz Linden: I don't think that I understand the problem... you can tell it to use a local lib in favor of one it has to fetch
[13:20] Boroondas Gupte: ah, good
[13:21] Robin Cornelius: you kept saying sources, using a local lib is not using sources, that was the confusion
[13:21] Oz Linden: building with later versions of VS is a separate issue... one I'd like to support, but separate
[13:21] Oz Linden: sorry
[13:21] Morgaine Dinova: Prebuilt works, but that doesn't mean it's not a mess. It's hanging together on a 3-way prayer of binary compatibility, system, prebuilts and the new compile.
[13:23] Oz Linden: Well, in theory we should all build every bit of sw we use from source, but we don't
[13:23] Oz Linden: there's a happy medium somewhere, the goal here is to support both models equally
[13:24] Oz Linden: and to have one framework for doing cross-platform builds of the viewer and everything it depends on
[13:24] Boroondas Gupte: Will the new system allow choosing between pre-build, from-source-build and system-instealled libs on a per-lib basis?
[13:24] Oz Linden: yes
[13:24] Boroondas Gupte: :-D
[13:25] Morgaine Dinova: I'm worried by the security aspects of prebuilt distribution, especially after the Emerald saga.
[13:25] Oz Linden: So all that should, as I said, be rolling out soon
[13:25] Latif Khalifa: how is converting the other internal teams to the viewer-development based code going?
[13:25] Oz Linden: well, if you can't trust us, then you may as well pack up and go... after all, you're implicitly trusting our grid
[13:26] Oz Linden: Latif... good question
[13:26] Oz Linden: Some (ECC and Display Names, for example) are fully converted
[13:26] Morgaine Dinova: Oz: not about trust in Lindens, but remember that your client setup is replicated by the TPVs
[13:26] Tillie Ariantho: I guess Morgaine more wants a system to compile her own 3rd party clients from their sources. :)
[13:26] Boroondas Gupte: well, we only have to trust the grid in a limited way ... about as far as we have to trust the software that our mail providers run on their servers
[13:26] Oz Linden: I'm not sure yet about others... just sent a query about that today but have not gotten any answers yet
[13:27] Latif Khalifa: I'm guessing mesh viewer will be opensource once it goes into public beta
[13:27] Morgaine Dinova: Tillie: no, you've misunderstood it completely
[13:27] Tillie Ariantho: ah. :P
[13:27] Latif Khalifa: so it might be a good thing to get them started on the conversion :)
[13:27] Oz Linden: That's the ECC team, Latif
[13:28] Latif Khalifa: Oh, cool, so they're ready
[13:28] Oz Linden: (I know... I don't have the names straight either)
[13:28] Jonathan Yap: What does ECC stand for?
[13:28] Tillie Ariantho: What means ECC again? External Client Contributors? ;P
[13:28] Oz Linden: no ... something Commerce something
[13:28] Oz Linden: Creators?
[13:28] Tillie Ariantho: Episcopal Church of Churning? ;)
[13:29] Latif Khalifa: I know Nyx and rendering folks call their team "Shining" ;)
[13:29] Oz Linden: I'm terrible with names... I really do wish I had a RL HUD that would put names over everyones head :-)
[13:29] Tillie Ariantho: Maybe its "Ehhhh, Content Creators! O.o" ;)
[13:29] Latif Khalifa: hehehe
[13:29] Gooden Uggla: /me makes a note to send nyx a jack nicholson av and an axe
[13:29] Oz Linden: yeah... TheShining is the codename for viewer dev within ECC
[13:30] Jonathan Yap: Oz, talk to someone at MIT, I bet they can give you something that fits over one eye.
[13:30] Latif Khalifa: Oz, the goal is to base all viwer development of viewer-developent repo, right?
[13:30] Oz Linden: The Media Lab is just down the street...
[13:30] Gooden Uggla: error control & content?
[13:31] Oz Linden: Ultimately, all viewer code must go through viewer-development in order to ship, so yes, they need to be based on it
[13:31] Tillie Ariantho: Only ECC I find on LL pages is Embedded Channel Conference (ECC) But that's Intel stuffs. :P
[13:31] Oz Linden: but some may not have converted yet... I don't know
[13:31] Latif Khalifa: that will make other teams decision to make their work public easer too I hopw
[13:31] Latif Khalifa: hope too
[13:31] Oz Linden: its' a new org name and not really important externally
[13:31] Tillie Ariantho: me too
[13:31] Gooden Uggla: oops Error Checking and Correction
[13:32] Oz Linden: Well, I'm encouraging everyone to open early and often... we'll see
[13:33] Oz Linden: they've got to be open to be released, though
[13:33] Morgaine Dinova: If many scrums are currently using their own repos, I guess we can "look forward" to a future of large changeset dumps into bitbucket, giving everyone a huge merge headache.
[13:33] Oz Linden: well, the merge headaches should not be bad, actually
[13:34] Latif Khalifa: There is nothing wrong with developing features in public Oz (mething) even though no product is released yet
[13:34] Oz Linden: because they have to have merged out from viewer-development (should have made that name shorter) before they can be pulled it, which means they've done all that work.
[13:34] Oz Linden: so any merges should just be with any local work you've got
[13:35] Oz Linden: I think that developing in public is good (but then you probably could have guessed that)
[13:36] Boroondas Gupte: you can rename repos on bitbucket, btw.
[13:36] Oz Linden: So... getting back to that issues list...
[13:36] Boroondas Gupte: would require everyone who has put the repo into their config to update that, but other than that it should work seamless
[13:37] Oz Linden: First... Boroondas... have you checked to see how many of these are somewhere in the Product Backlog?
[13:37] Oz Linden: I recognize a couple of them
[13:38] Boroondas Gupte: The overall story made it to the old, spreadsheet based backlog on the "ideas" tab. Haven't checked the jira backlog, yet.
[13:39] Oz Linden: I suspect it's still there then... I"m pretty sure Esbee copied everything somewhere
[13:39] Oz Linden: I'll look though
[13:40] Oz Linden: I suspect that these all fall into one of: 1) 64 bit , or 2) compatibility with some later version of something than LL uses, correct?
[13:41] Boroondas Gupte: some might be specific to standalone (i.e. relevant for 32bit standalone, too)
[13:41] Boroondas Gupte: other then that, yes
[13:41] Tillie Ariantho: /me still waiting for a 64bit Windows client that doesnt crash with a memory error anymore like the 32bit one. :P
[13:41] Oz Linden: If it's not to solve one of the above, why do standalone builds?
[13:42] Oz Linden: Masochism aside, that is...
[13:42] Boroondas Gupte: distributions often require packagers to use system libs
[13:42] Boroondas Gupte: so those would use standalone, too
[13:42] Boroondas Gupte: but for me it's 64bit
[13:43] Oz Linden: Is anyone actually getting an SL TPV into some distribution?
[13:43] Oz Linden: I'm trying to make sure that I understand the underlying problem
[13:43] Oz Linden: bothe of the ones I enumerated I understand and want to fix....
[13:44] Boroondas Gupte: well, Techwolf maintains a portage overlay for gentoo with most major TPVs (and the official LL viewers) in it.
[13:44] Gooden Uggla: a suggestion: have someone compile each TPV from the components to make sure it's the same size as the TPV-offered d/l
[13:44] Boroondas Gupte: Robin packages for debian
[13:44] Oz Linden: I'm trying to make sure that I'm not missing another one
[13:44] Gooden Uggla: that was an indicator in the past of mischief :)
[13:45] Oz Linden: Anyone who wants to do those checks is welcome to do so
[13:45] Oz Linden: I'll be happy to hear the results
[13:46] Boroondas Gupte: size can depend on optimization flags and compiler version ... I don't know how reliable those results would be
[13:46] Latif Khalifa: Is this "autobuld" tool something related to splitting viewer-development into several repositories?
[13:46] Gooden Uggla: let's just say that a large difference would be a tell
[13:46] Oz Linden: It's going to make that split more manageable
[13:47] Morgaine Dinova: It's because of getting it into distros that any extra scripts become a liability and a hurdle. Ideally want just a plain cmake + make.
[13:47] Oz Linden: Currently, the plan is that shortly after we switch the viewer builds to using autobuild, we'll split out the common code to its own repo
[13:47] Ardy Lay: In the not too distanst past, LL published a viewer for Linux that was a HUGE download compared to the previous release. I think the symbol strip step in the process got skipped or something. I didn't fetch it to look.
[13:48] Morgaine Dinova: And distros have no truck with prebuilts at all of course.
[13:48] Oz Linden: Well, we can't help that part... we don't have sources for everything
[13:48] Oz Linden: or at least not ones we can distribute
[13:49] Morgaine Dinova: Those parts shouldn't be in the build at all. You did very well with KDU for example to keep it out of the actual build.
[13:49] Oz Linden: there will be a new repo called indra-common, and a bunch of things will be removed from viewer-development and moved over to indra-common
[13:50] Oz Linden: I don't want to get into KDU at the moment...
[13:50] Oz Linden: The indra-common repo will also be under the LGPL, of course
[13:52] Oz Linden: The history there is that once upon a time the server and the viewer were in one tree... some time ago (07 ish?) they forked, and some changes in the "common" modules were not kept in sync
[13:52] Oz Linden: now the common stuff is being put into indra-common, and that will be used by both again
[13:53] Oz Linden: Which does mean that any changes for indra-common will have to be reviewed by server devs as well, and we're going to try to radically increase the unit test coverage there
[13:54] Boroondas Gupte: sounds good
[13:54] Latif Khalifa: yeah
[13:54] Morgaine Dinova: Is the meaning of "indra" lost in the mists of time now? <grin>
[13:54] Boroondas Gupte: it's a hindu god
[13:54] Oz Linden: I assume someone knows what it was, but I don't
[13:54] Latif Khalifa: all grid names an projects were hindu gods
[13:54] Boroondas Gupte: yeah
[13:55] Oz Linden: and that may be it... the grids are also named for gods
[13:55] Boroondas Gupte: "Agni" is the god of fire :-P
[13:55] Latif Khalifa: hehe
[13:55] Jonathan Yap: What god is Meshutopia (sp?) named for? :P
[13:56] Morgaine Dinova: Aditi should have been named Loki, since it's where mischief happens :P
[13:56] Oz Linden: So... on that list of build issues... can we go through them and make sure that for each it is clear whether it is driven by 64bit or some other dependency?
[13:56] Boroondas Gupte: Loki is a greek figure, though, isn't he?
[13:56] Oz Linden: it will help me get them prioritized
[13:56] Latif Khalifa: I have to go, thanks for your time Oz, take care everybody
[13:56] Oz Linden: Norse
[13:56] Morgaine Dinova: Cya Latif
[13:56] Boroondas Gupte: ah
[13:56] Oz Linden: bye Latif
[13:57] Oz Linden: Something for everyone to think about....
[13:57] Boroondas Gupte: well, we might want to start with the ones from Techwolf's repo: https://lists.secondlife.com/pipermail/opensource-dev/2010-August/003112.html
[13:57] Boroondas Gupte: SNOW-746
[13:57] Oz Linden: LL is creating Project Viewers for new stuff (DN, mesh, ...)
[13:58] Oz Linden: How can we as the open devs do the same so that people who want to help test have an easy place to look?
[13:58] Oz Linden: Ok, Boroondas
[13:59] Oz Linden: By the way - we had several thousand unique users using Development viewers last week
[13:59] Oz Linden: !!!!
[13:59] Morgaine Dinova: Definition of Project Viewer?
[14:00] Oz Linden: A Project Viewer is some substantial feature released on its own ... like a First Look.
[14:00] Bronson Blackadder: on snowstorm right now
[14:00] Morgaine Dinova: That's pretty impressive, thousands of devs
[14:00] Jonathan Yap: Oz, were those people on long-standing accounts or new ones that might have downloaded a development viewer accidentally?
[14:00] Boroondas Gupte: https://wiki.secondlife.com/wiki/Viewer_Integration_and_Release_Processes #Project
[14:00] Oz Linden: There can be more than one PV at any one time, with different new stuff
[14:01] Morgaine Dinova: Oz: is a "Project Viewer" open source?
[14:01] Oz Linden: I don't have that stat, Jonathan, but I'm not sure I could tell, since some people may have created alts just to try the viewers
[14:01] Boroondas Gupte: Morgaine, some will be, some not: "Project repositories may be built as needed by the developers; viewers produced from Project repositories may be made available for public testing at times chosen by the development team."
[14:01] Oz Linden: The expecteation is that a PV will publish source no later than when they release the viewer
[14:02] Morgaine Dinova: So the answer is No
[14:02] Techwolf Lupindo: /me returns and reads the chat from the beginning of this OH...sorry for being afk....but....
[14:02] Oz Linden: it's not a hard rule, but Display Names did it (a couple of days late due to conversion problems)
[14:02] Oz Linden: No, note that I said "no later" - it can (and should, I hope) be earlier
[14:03] Oz Linden: Aside from Snowstorm and TheShining, most of LL is still getting used to this 'open' thing
[14:03] Oz Linden: they'll come around
[14:04] Morgaine Dinova: OK, so the sull answer is "Project Viewers" start off closed source, but at some point decided by each team become open source, at least on final release.
[14:04] Morgaine Dinova: full*
[14:04] Boroondas Gupte: They can start off open source, if they want
[14:04] Oz Linden: The answer is that it's flexible, really.
[14:04] Bronson Blackadder: what is the shining?
[14:05] Boroondas Gupte: rendering team, I think?
[14:05] Morgaine Dinova: Bor: no team has committed to joining Snowstorm as full open yet though. (AFAWK)
[14:05] Gooden Uggla: i believe the display name viewer that was available is already obsolete
[14:05] Oz Linden: Any project within the Lab can choose when to be open... but they must be open in order to release in the main viewer, and the expectation is that they will be to release as a PV
[14:05] Gooden Uggla: so how open does it need to be?
[14:06] Oz Linden: I don't understand the question, Gooden ... how open is open?
[14:06] Techwolf Lupindo: OK. I came back from RL to here and read that backlog....
[14:07] Boroondas Gupte: wb Techwolf
[14:07] Techwolf Lupindo: All I have to say is WTF?
[14:07] Oz Linden: how articulate these wolves are....
[14:07] Bronson Blackadder: wheres the forks?
[14:08] Gooden Uggla: the viewer that was d/l-ed was a one-shot to start testing on aditi
[14:08] Techwolf Lupindo: I though the goal was to use cmake and dump the devolope.py and viewer_manifast.py and use cpack to fix all the installer butgs.
[14:08] Gooden Uggla: it's already been scrapped and changed, should that voewer need to be opened?
[14:08] Oz Linden: sorry Tech... I don't have time to restart that now (I'm going have to go start cooking dinner in a minute)
[14:08] Techwolf Lupindo: Dim spent at least 15 hours figuring out why media didn't work. Guess what it came done to, the installer and viewermanifest wasn't registering the .dlls.
[14:09] Techwolf Lupindo: If cpack was used, that would never be a problem.
[14:09] Oz Linden: that is off topic for this meeting
[14:09] Techwolf Lupindo: Fine. Im'e out of here.
[14:10] Oz Linden: I'm sure that you have a question, Gooden, but I don't understand it. Try agian, and don't use any pronouns
[14:11] Gooden Uggla: i believe i'll ask elsewhere
[14:12] Oz Linden: ok
[14:12] Oz Linden: I've got to go be a homemaker and throw a frisbee for my puppy
[14:12] Oz Linden: Thanks for coming everyone
[14:13] Tillie Ariantho: bye =)
[14:13] Morgaine Dinova: Oz: I strongly recommend that you drop that Moderator crap, because you're alienating good developers. It's not needed.
[14:13] Tillie Ariantho: ^^
[14:13] Boroondas Gupte: yeah, you scared Techwolf away. I'm sure he had something relevant to say.

Generated with SLog Wikifier

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Oz_Linden/Office_Hours_Archive_2010-09-15&oldid=1036633"