Second Life Wiki - User contributions [en]

Antialiasing

2010-11-30T23:04:45Z

Q Linden: A few tweaks for instructions and to clarify the status of it

<noinclude>{{KBmaster}}</noinclude>
{{TOCright}}

== About ==

"Antialiasing" sounds like a geeky term but its visual effects can be understood easily.

First of all, you may know "Anti" is often used as a prefix to mean "against", so why do we need to be against "aliasing"? In computer graphics, "[http://dictionary.reference.com/browse/aliasing aliasing]" (and [http://en.wikipedia.org/wiki/Aliasing an expanded technical definition]) refers to the dreaded ''jaggies'' that appear, noticeably on curved edges. If you've wondered why the Second Life Viewer's graphics appear rougher than other 3D experiences you're accustomed to, this is part of the reason. If you've ever seen smoothed fonts in your web browser, they've probably been antialiased, too.

Thus, '''antialiasing is a way to smooth those jaggies'''. To understand, I must show you, before and after:

[[File:Antialiasing_and_anisotropic_filtering_ON_and_OFF.png]]

''See the difference?'' The left image has antialiasing and anisotropic filtering (a complementary feature) OFF, while the right has it ON — antialiasing is at 4x. There were some animated objects in the scene and a relog was required, so ignore the color differences and '''focus on the edges and clarity of textures'''. Notice how the abstract doodling at the right-hand side of the right is much more legible?

You should also see more examples from fellow Residents:

* '''[http://analutetia.com/2009/12/26/tips-tricks-turn-on-anti-aliasing-insl/ Ana Lutetia's Anti-Aliasing Tutorial]'''
* '''[http://www.flickr.com/photos/opensourceobscure/2403716655/sizes/o/ OpenSource Obscure's example]'''

'''If you have a [[graphics card]] that meets or exceeds our [http://secondlife.com/support/sysreqs.php System ''Recommendations''], antialiasing may be supported. For many graphics cards, it comes at a minimal performance cost.''' On slower graphics cards, you may be able to turn on antialiasing, but it may cause a noticeable performance hit, or even bugs or crashes — so you should experiment and see what's best for you.

Antialiasing support has changed in recent viewer releases as part of a major rework of Second Life's graphics systems. It will continue to change for the next few releases. This may mean that support for antialiasing may change or be removed for a given graphics card.

== What use is antialiasing? ==

Antialiasing is useful whenever you're looking at Second Life, since it improves overall image quality.

In particular, '''antialiasing is great if you're making videos or taking product pictures for Xstreet/Marketplace listings''', because it makes your goods appear much crisper with fewer "digital artifacts". (This is part of why [[Torley]] wrote this, because he sees so many marketplace items that would benefit from being shown in their full glory — antialiasing ''isn't'' cheating.)

== Great, so how do I enable antialiasing? ==

# Choose '''Me''' menu > '''Preferences'''.
# Click the '''Graphics''' tab.
# Click the '''Hardware''' button. (If you've never been here before, don't worry, it's fairly un-obvious but you'll wonder how you ever lived without it after!)
# Click the '''Antialiasing''' dropdown and change it from '''Disabled''' to '''2x''' or even '''4x''' (which [[Torley]] prefers as a balance).
#* Related, you may also want to check '''Anisotropic Filtering'''. This makes textures at angles (like rotated signs in the distance) appear sharper.
# Click '''OK'''.
# Restart the Second Life Viewer. Now compare. The difference should be subtle yet noticeable.

Ooh, video!

{{KBvideo|Q6vuOubWik0|640|505|type=youtube}}

{{KBnote|If you don't see a change even after you restart the Viewer, it's possible your graphics card drivers are overriding Second Life's own antialiasing.}}

== What antialiasing level is the best? ==

Obviously, higher is better but '''16x''' (or even '''32x''' if that's available) is quite taxing unless you have a very beefy graphics card. Here's why: to antialias, what you see is effectively rendered at a ''higher-resolution multiple'' of itself, then scaled down. Edges look smoother because there's a higher quality image to begin with. But to render something at 16x compared to 4x requires a lot more power — and unless you're terribly discerning, you may not notice the difference. To some eyes 16x is too much of a good thing; everything on the screen, including text on avatar nametags, is smoothed and 16x may make them too soft.

Antialiasing is completely undoable, so again, ''experiment'' to find a balance.

== Where can I learn more? ==

Antialiasing is a general computer graphics concept, so there's [http://lmgtfy.com/?q=what+is+antialiasing plenty of info on Google] and beyond.

Viewer Integration and Release Processes

2010-10-07T15:52:07Z

Q Linden: /* Development Integration Criteria */

{{Project Snowstorm Nav}}

This page describes how Viewer development projects are organized, including the Mercurial (hg) repositories, builds, and the integration and release processes through which changes move to get from the developer (either inside or outside Linden Lab) to the Second Life Viewer.

There are three core hg repositories (each repository is in effect a branch; the processes described here do not rely on using the hg branching features within a repository):
* [[#Development|Development]] is the integration trunk
* [[#Beta|Beta]] is used to test and stabilize releases and build beta releases
* [[#Release|Release]] is used to build official stable releases
all three of these repositories are used by both Linden Lab development teams and open source developers; they are accessible at hg.secondlife.com, but only the specific Linden team responsible for each one has commit access to it. Detailed descriptions of each, and the processes for moving changes between them, are below.
__TOC__
<br clear="all"/>

===Development===

[[Image:Development.png|right|caption="Project and Development repositories/branches"]]

'''Location:''' [http://hg.secondlife.com/viewer-development http://hg.secondlife.com/viewer-development]

:'''This is the conceptual ‘trunk’ from which all development, both inside and outside Linden Lab, should be derived.'''

It is built continuously, with the resulting viewers being publicly available (from [[Downloading test builds]] and soon also from the [http://secondlife.com/support/downloads main downloads page]).

Any active viewer development, whether for feature development or bug fixes, pulls from this repository to a [[#Project|Project]] repository, and tracks all changes made in Development as work is done in that Project repository. Code is pulled back to this repository for integration (see [[#Development Integration Criteria|Development Integration Criteria]] below).

Ideally, any build from this repository is a candidate for the next Beta viewer release.

===Project===

'''Location:''' ''determined by the development team, but somewhere at hg.secondlife.com is encouraged''

Any development, whether a single engineer fixing a minor bug or a large team building a major feature, is done in a Project repository that pulls from Development. Large projects will likely have individual repositories pulling from and pushing to their team Project repository; how this is managed and tracks changes made to Development is under the control of the developer(s) on the project.

There may be any number of other repositories created by project teams or developers either inside or outside Linden Lab; these are ''Project'' repositories. The default channel identifier built from these repositories is "Second Life Developer" (projects that plan to make test viewers publicly available, which is encouraged, should change this to a project-specific value in those viewers).

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.

When development is complete '''and the [[#Development Integration Criteria|Development Integration Criteria]] have been satisfied''' changes from a Project repository are moved back to the Development repository. For Linden developers, this can be a push (contact the Snowstorm Team to be configured for write access), or for open source contributors a pull by the Snowstorm Team.

: '''Note:''' Developers should consider the viewer-development branch to be a "clean" trunk. It's not "pristine" -- we don't gate checkins through a QA process. But developers should feel very confident BEFORE checking in to viewer-development, because other projects, both internal and external, are pulling from this repository on a daily basis. They should feel confident in doing so, as it may require work to merge the changes. Consequently, '''developers must be willing to support their checkins.'''

: ''If you are not prepared to respond to bug reports on a high-priority basis all the way through the release process, '''you should not check in'''.''

==Development Integration Criteria==

In order to be eligible to be pulled into the Development repository, the changes in a Project repository must satisfy all of the following criteria:

# '''Functionality must have been reviewed and accepted by the Product Owner'''
#: Review is based on the requirements/user stories defined at the beginning of a sprint, and then at the end of a sprint during Acceptance Testing. For Linden development teams, these checks are the normal sprint reviews, not an additional step. For open source developers, the Snowstorm Team will coordinate these reviews with the appropriate Linden reviewers.
# '''Design and code must have been reviewed by competent reviewers.'''
#: In this context, “competent” means appropriate subject matter experts for the code that is modified. Linden development teams determine for themselves who the competent reviewers are; for open source contributions, the Snowstorm Team will determine the appropriate reviews.
#:* If there are changes to code or protocols shared between the viewer and the simulator, those changes must include unit tests that at minimum validate that the behavior before and after the change is compatible. If that is not possible due to the nature of the change, then the change must include documentation on how the interfaces are changed, and the relevant simulator developers must review and approve them (for open source contributions, the Snowstorm Team will coordinate and facilitate these reviews).
# '''There must be a test plan'''
#: The test plan must describe in detail how the modified behavior can be validated and tested. We provide a handy [[Test_Script_Template | test plan template]] to help make this trouble free.
# '''The Project repository must have merged in the latest changes from Development.'''
#: The results must be validated by building viewers for all platforms and doing at least minimal viewer testing. ''Breaking the Development build is considered bad practice and may incur [http://www.ehow.com/about_5108486_karmic-debt.html karmic debt].''
# '''There must be [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf Contribution Agreement]s on file from all contributors to the change if the Project repository contains changes made by non-Lindens.'''

When these criteria have been met, the development team may integrate into the Development repository; see [[How To Submit A Viewer Change]].

If a checkin causes excessive instability or breaks customer experience in important ways, it may be reverted and the developer will have to fix the issues and re-integrate. We hope not to have to do this often, but we will make the reversion decision quickly, because reversion usually requires reverting all later checkins as well.

==Beta and Release==

To create the Beta and Release Viewers, the changes on the Development repository are moved through the [[#Beta Repository|Beta]] and [[#Release|Release]] repositories following the [[#Beta and Release Process|Beta and Release Process]].

These are continuous processes - soon (preferably within a week) after one set of changes has been moved from Beta to Release, the next Beta cycle is begun by moving the current Development changes to Beta to begin the next cycle. The number of weekly Beta cycles, and thus the frequency of windows for moving from Development to Beta, is determined by the Beta test results.

The targets are that we will have weekly Beta releases, with stable main viewer releases monthly.

[[Image:DevelopmentToRelease.png|right|caption="Development through Beta to Release"]]

===Beta Repository===

'''Location:''' [http://hg.secondlife.com/viewer-beta http://hg.secondlife.com/viewer-beta]

: The Integration and QA team tags Development and pulls from that tag into the Beta repository (since the Beta repository will contain only change sets that are already in Development, this pull does not require any merges).

: Final QA and stabilization are done using builds from the Beta repository; builds from this repository are released weekly on the “Second Life Beta Viewer” channel.

: Any bug fixes on this repository are immediately pulled to the Development repository by the Snowstorm Team.

===Release Repository===

'''Location:''' [http://hg.secondlife.com/viewer-release http://hg.secondlife.com/viewer-release]

: When the Snowstorm Team decides that the Beta branch is ready for release (which we expect to be after 2-4 weeks of testing and stabilization), the Integration team pulls changes from Beta into the Release repository (this is the only path into the Release repository, so this does not require any merges), where it is tagged and built to produce the viewer released on the “Second Life Release” channel.

==Beta and Release Process==

The process by which the Development code is promoted to an official numbered Viewer release is:

# The Integration and QA team adds a beta tag to Development.
# The Release Manager
## Pulls changes from the beta tag on Development to the Beta repository (this should not require any merge).
## Builds branch on Beta
## Creates a release document that includes test plan information and the list of all the changes included in the build (list of JIRAs, etc). Proper attention to detail during development should make this simple.
## Offer build to QA for testing and evaluation
# In QA, the integration test team:
## Executes the set of test plans for all of the changes included
## Performs a general smoke test on overall functionality
## Identifies overall quality and level of risk for release
# The Snowstorm Team evaluates quality, risk and feature set and decides whether or not to release the build as Beta. Options are:
#* ''Fail'': this beta candidate is rejected and the process starts over at some different tag on Development (step 1).
#* ''Fix First'': specific bugs / issues are identified that must be fixed before ship. These bugs are fixed in the Beta repository.
#** Fixes made to the Beta repository are merged to Development by the Snowstorm Team as soon as they are found to be complete.
#* ''Ship'': the Beta is ready as-is.
# Once a build is approved for ship, the Release team does its magic to get the build into the field as a Beta build on the “Second Life Beta Viewer” channel.
# Once a Beta is in the field, we watch for new bugs, crash rate, performance, and other data. If the Beta needs further iteration, we might iterate multiple times on the Beta branch (return to step 4).
# Once the Snowstorm Team decides the Beta is of sufficient quality to ship as an official viewer, the Release team:
## Tags the Beta branch
## Pulls from the tag on Beta to Release
## Tags and builds from the Release repository.
## Releases on the “Second Life Viewer” channel.

Viewer Integration and Release Processes

2010-10-07T15:51:49Z

Q Linden: /* Project */

{{Project Snowstorm Nav}}

This page describes how Viewer development projects are organized, including the Mercurial (hg) repositories, builds, and the integration and release processes through which changes move to get from the developer (either inside or outside Linden Lab) to the Second Life Viewer.

There are three core hg repositories (each repository is in effect a branch; the processes described here do not rely on using the hg branching features within a repository):
* [[#Development|Development]] is the integration trunk
* [[#Beta|Beta]] is used to test and stabilize releases and build beta releases
* [[#Release|Release]] is used to build official stable releases
all three of these repositories are used by both Linden Lab development teams and open source developers; they are accessible at hg.secondlife.com, but only the specific Linden team responsible for each one has commit access to it. Detailed descriptions of each, and the processes for moving changes between them, are below.
__TOC__
<br clear="all"/>

===Development===

[[Image:Development.png|right|caption="Project and Development repositories/branches"]]

'''Location:''' [http://hg.secondlife.com/viewer-development http://hg.secondlife.com/viewer-development]

:'''This is the conceptual ‘trunk’ from which all development, both inside and outside Linden Lab, should be derived.'''

It is built continuously, with the resulting viewers being publicly available (from [[Downloading test builds]] and soon also from the [http://secondlife.com/support/downloads main downloads page]).

Any active viewer development, whether for feature development or bug fixes, pulls from this repository to a [[#Project|Project]] repository, and tracks all changes made in Development as work is done in that Project repository. Code is pulled back to this repository for integration (see [[#Development Integration Criteria|Development Integration Criteria]] below).

Ideally, any build from this repository is a candidate for the next Beta viewer release.

===Project===

'''Location:''' ''determined by the development team, but somewhere at hg.secondlife.com is encouraged''

Any development, whether a single engineer fixing a minor bug or a large team building a major feature, is done in a Project repository that pulls from Development. Large projects will likely have individual repositories pulling from and pushing to their team Project repository; how this is managed and tracks changes made to Development is under the control of the developer(s) on the project.

There may be any number of other repositories created by project teams or developers either inside or outside Linden Lab; these are ''Project'' repositories. The default channel identifier built from these repositories is "Second Life Developer" (projects that plan to make test viewers publicly available, which is encouraged, should change this to a project-specific value in those viewers).

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.

When development is complete '''and the [[#Development Integration Criteria|Development Integration Criteria]] have been satisfied''' changes from a Project repository are moved back to the Development repository. For Linden developers, this can be a push (contact the Snowstorm Team to be configured for write access), or for open source contributors a pull by the Snowstorm Team.

: '''Note:''' Developers should consider the viewer-development branch to be a "clean" trunk. It's not "pristine" -- we don't gate checkins through a QA process. But developers should feel very confident BEFORE checking in to viewer-development, because other projects, both internal and external, are pulling from this repository on a daily basis. They should feel confident in doing so, as it may require work to merge the changes. Consequently, '''developers must be willing to support their checkins.'''

: ''If you are not prepared to respond to bug reports on a high-priority basis all the way through the release process, '''you should not check in'''.''

==Development Integration Criteria==

In order to be eligible to be pulled into the Development repository, the changes in a Project repository must satisfy all of the following criteria:

# '''Functionality must have been reviewed and accepted by the Product Owner'''
#: Review is based on the requirements/user stories defined at the beginning of a sprint, and then at the end of a sprint during Acceptance Testing. For Linden development teams, these checks are the normal sprint reviews, not an additional step. For open source developers, the Snowstorm Team will coordinate these reviews with the appropriate Linden reviewers.
# '''Design and code must have been reviewed by competent reviewers.'''
#: In this context, “competent” means appropriate subject matter experts for the code that is modified. Linden development teams determine for themselves who the competent reviewers are; for open source contributions, the Snowstorm Team will determine the appropriate reviews.
#:* If there are changes to code or protocols shared between the viewer and the simulator, those changes must include unit tests that at minimum validate that the behavior before and after the change is compatible. If that is not possible due to the nature of the change, then the change must include documentation on how the interfaces are changed, and the relevant simulator developers must review and approve them (for open source contributions, the Snowstorm Team will coordinate and facilitate these reviews).
# '''There must be a test plan'''
#: The test plan must describe in detail how the modified behavior can be validated and tested. We provide a handy [[Test_Script_Template | test plan template]] to help make this trouble free.
# '''The Project repository must have merged in the latest changes from Development.'''
#: The results must be validated by building viewers for all platforms and doing at least minimal viewer testing. ''Breaking the Development build is considered bad practice and may incur [http://www.ehow.com/about_5108486_karmic-debt.html karmic debt].''
# '''There must be [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf Contribution Agreement]s on file from all contributors to the change if the Project repository contains changes made by non-Lindens.'''

When these criteria have been met, the development team may integrate into the Development repository; see [[How To Submit A Viewer Change]].

==Beta and Release==

To create the Beta and Release Viewers, the changes on the Development repository are moved through the [[#Beta Repository|Beta]] and [[#Release|Release]] repositories following the [[#Beta and Release Process|Beta and Release Process]].

These are continuous processes - soon (preferably within a week) after one set of changes has been moved from Beta to Release, the next Beta cycle is begun by moving the current Development changes to Beta to begin the next cycle. The number of weekly Beta cycles, and thus the frequency of windows for moving from Development to Beta, is determined by the Beta test results.

The targets are that we will have weekly Beta releases, with stable main viewer releases monthly.

[[Image:DevelopmentToRelease.png|right|caption="Development through Beta to Release"]]

===Beta Repository===

'''Location:''' [http://hg.secondlife.com/viewer-beta http://hg.secondlife.com/viewer-beta]

: The Integration and QA team tags Development and pulls from that tag into the Beta repository (since the Beta repository will contain only change sets that are already in Development, this pull does not require any merges).

: Final QA and stabilization are done using builds from the Beta repository; builds from this repository are released weekly on the “Second Life Beta Viewer” channel.

: Any bug fixes on this repository are immediately pulled to the Development repository by the Snowstorm Team.

===Release Repository===

'''Location:''' [http://hg.secondlife.com/viewer-release http://hg.secondlife.com/viewer-release]

: When the Snowstorm Team decides that the Beta branch is ready for release (which we expect to be after 2-4 weeks of testing and stabilization), the Integration team pulls changes from Beta into the Release repository (this is the only path into the Release repository, so this does not require any merges), where it is tagged and built to produce the viewer released on the “Second Life Release” channel.

==Beta and Release Process==

The process by which the Development code is promoted to an official numbered Viewer release is:

# The Integration and QA team adds a beta tag to Development.
# The Release Manager
## Pulls changes from the beta tag on Development to the Beta repository (this should not require any merge).
## Builds branch on Beta
## Creates a release document that includes test plan information and the list of all the changes included in the build (list of JIRAs, etc). Proper attention to detail during development should make this simple.
## Offer build to QA for testing and evaluation
# In QA, the integration test team:
## Executes the set of test plans for all of the changes included
## Performs a general smoke test on overall functionality
## Identifies overall quality and level of risk for release
# The Snowstorm Team evaluates quality, risk and feature set and decides whether or not to release the build as Beta. Options are:
#* ''Fail'': this beta candidate is rejected and the process starts over at some different tag on Development (step 1).
#* ''Fix First'': specific bugs / issues are identified that must be fixed before ship. These bugs are fixed in the Beta repository.
#** Fixes made to the Beta repository are merged to Development by the Snowstorm Team as soon as they are found to be complete.
#* ''Ship'': the Beta is ready as-is.
# Once a build is approved for ship, the Release team does its magic to get the build into the field as a Beta build on the “Second Life Beta Viewer” channel.
# Once a Beta is in the field, we watch for new bugs, crash rate, performance, and other data. If the Beta needs further iteration, we might iterate multiple times on the Beta branch (return to step 4).
# Once the Snowstorm Team decides the Beta is of sufficient quality to ship as an official viewer, the Release team:
## Tags the Beta branch
## Pulls from the tag on Beta to Release
## Tags and builds from the Release repository.
## Releases on the “Second Life Viewer” channel.

Viewer Integration and Release Processes

2010-10-07T15:50:59Z

Q Linden: /* Project */

{{Project Snowstorm Nav}}

This page describes how Viewer development projects are organized, including the Mercurial (hg) repositories, builds, and the integration and release processes through which changes move to get from the developer (either inside or outside Linden Lab) to the Second Life Viewer.

There are three core hg repositories (each repository is in effect a branch; the processes described here do not rely on using the hg branching features within a repository):
* [[#Development|Development]] is the integration trunk
* [[#Beta|Beta]] is used to test and stabilize releases and build beta releases
* [[#Release|Release]] is used to build official stable releases
all three of these repositories are used by both Linden Lab development teams and open source developers; they are accessible at hg.secondlife.com, but only the specific Linden team responsible for each one has commit access to it. Detailed descriptions of each, and the processes for moving changes between them, are below.
__TOC__
<br clear="all"/>

===Development===

[[Image:Development.png|right|caption="Project and Development repositories/branches"]]

'''Location:''' [http://hg.secondlife.com/viewer-development http://hg.secondlife.com/viewer-development]

:'''This is the conceptual ‘trunk’ from which all development, both inside and outside Linden Lab, should be derived.'''

It is built continuously, with the resulting viewers being publicly available (from [[Downloading test builds]] and soon also from the [http://secondlife.com/support/downloads main downloads page]).

Any active viewer development, whether for feature development or bug fixes, pulls from this repository to a [[#Project|Project]] repository, and tracks all changes made in Development as work is done in that Project repository. Code is pulled back to this repository for integration (see [[#Development Integration Criteria|Development Integration Criteria]] below).

Ideally, any build from this repository is a candidate for the next Beta viewer release.

===Project===

'''Location:''' ''determined by the development team, but somewhere at hg.secondlife.com is encouraged''

Any development, whether a single engineer fixing a minor bug or a large team building a major feature, is done in a Project repository that pulls from Development. Large projects will likely have individual repositories pulling from and pushing to their team Project repository; how this is managed and tracks changes made to Development is under the control of the developer(s) on the project.

There may be any number of other repositories created by project teams or developers either inside or outside Linden Lab; these are ''Project'' repositories. The default channel identifier built from these repositories is "Second Life Developer" (projects that plan to make test viewers publicly available, which is encouraged, should change this to a project-specific value in those viewers).

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.

When development is complete '''and the [[#Development Integration Criteria|Development Integration Criteria]] have been satisfied''' changes from a Project repository are moved back to the Development repository. For Linden developers, this can be a push (contact the Snowstorm Team to be configured for write access), or for open source contributors a pull by the Snowstorm Team.

: '''Note:''' Developers should consider the viewer-development branch to be a "clean" trunk. It's not "pristine" -- we don't gate checkins through a QA process. But developers should feel very confident BEFORE checking in to viewer-development, because other projects, both internal and external, are pulling from this repository on a daily basis. They should feel confident in doing so, as it may require work to merge the changes. Consequently, '''developers must be willing to support their checkins.'''

: ''If you are not prepared to respond to bug reports on a high-priority basis all the way through the release process, '''you should not check in'''.''

If a checkin causes excessive instability or breaks customer experience in important ways, it may be reverted and the developer will have to fix the issues and re-integrate. We hope not to have to do this often, but we will make the reversion decision quickly, because reversion usually requires reverting all later checkins as well.

==Development Integration Criteria==

In order to be eligible to be pulled into the Development repository, the changes in a Project repository must satisfy all of the following criteria:

# '''Functionality must have been reviewed and accepted by the Product Owner'''
#: Review is based on the requirements/user stories defined at the beginning of a sprint, and then at the end of a sprint during Acceptance Testing. For Linden development teams, these checks are the normal sprint reviews, not an additional step. For open source developers, the Snowstorm Team will coordinate these reviews with the appropriate Linden reviewers.
# '''Design and code must have been reviewed by competent reviewers.'''
#: In this context, “competent” means appropriate subject matter experts for the code that is modified. Linden development teams determine for themselves who the competent reviewers are; for open source contributions, the Snowstorm Team will determine the appropriate reviews.
#:* If there are changes to code or protocols shared between the viewer and the simulator, those changes must include unit tests that at minimum validate that the behavior before and after the change is compatible. If that is not possible due to the nature of the change, then the change must include documentation on how the interfaces are changed, and the relevant simulator developers must review and approve them (for open source contributions, the Snowstorm Team will coordinate and facilitate these reviews).
# '''There must be a test plan'''
#: The test plan must describe in detail how the modified behavior can be validated and tested. We provide a handy [[Test_Script_Template | test plan template]] to help make this trouble free.
# '''The Project repository must have merged in the latest changes from Development.'''
#: The results must be validated by building viewers for all platforms and doing at least minimal viewer testing. ''Breaking the Development build is considered bad practice and may incur [http://www.ehow.com/about_5108486_karmic-debt.html karmic debt].''
# '''There must be [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf Contribution Agreement]s on file from all contributors to the change if the Project repository contains changes made by non-Lindens.'''

When these criteria have been met, the development team may integrate into the Development repository; see [[How To Submit A Viewer Change]].

==Beta and Release==

To create the Beta and Release Viewers, the changes on the Development repository are moved through the [[#Beta Repository|Beta]] and [[#Release|Release]] repositories following the [[#Beta and Release Process|Beta and Release Process]].

These are continuous processes - soon (preferably within a week) after one set of changes has been moved from Beta to Release, the next Beta cycle is begun by moving the current Development changes to Beta to begin the next cycle. The number of weekly Beta cycles, and thus the frequency of windows for moving from Development to Beta, is determined by the Beta test results.

The targets are that we will have weekly Beta releases, with stable main viewer releases monthly.

[[Image:DevelopmentToRelease.png|right|caption="Development through Beta to Release"]]

===Beta Repository===

'''Location:''' [http://hg.secondlife.com/viewer-beta http://hg.secondlife.com/viewer-beta]

: The Integration and QA team tags Development and pulls from that tag into the Beta repository (since the Beta repository will contain only change sets that are already in Development, this pull does not require any merges).

: Final QA and stabilization are done using builds from the Beta repository; builds from this repository are released weekly on the “Second Life Beta Viewer” channel.

: Any bug fixes on this repository are immediately pulled to the Development repository by the Snowstorm Team.

===Release Repository===

'''Location:''' [http://hg.secondlife.com/viewer-release http://hg.secondlife.com/viewer-release]

: When the Snowstorm Team decides that the Beta branch is ready for release (which we expect to be after 2-4 weeks of testing and stabilization), the Integration team pulls changes from Beta into the Release repository (this is the only path into the Release repository, so this does not require any merges), where it is tagged and built to produce the viewer released on the “Second Life Release” channel.

==Beta and Release Process==

The process by which the Development code is promoted to an official numbered Viewer release is:

# The Integration and QA team adds a beta tag to Development.
# The Release Manager
## Pulls changes from the beta tag on Development to the Beta repository (this should not require any merge).
## Builds branch on Beta
## Creates a release document that includes test plan information and the list of all the changes included in the build (list of JIRAs, etc). Proper attention to detail during development should make this simple.
## Offer build to QA for testing and evaluation
# In QA, the integration test team:
## Executes the set of test plans for all of the changes included
## Performs a general smoke test on overall functionality
## Identifies overall quality and level of risk for release
# The Snowstorm Team evaluates quality, risk and feature set and decides whether or not to release the build as Beta. Options are:
#* ''Fail'': this beta candidate is rejected and the process starts over at some different tag on Development (step 1).
#* ''Fix First'': specific bugs / issues are identified that must be fixed before ship. These bugs are fixed in the Beta repository.
#** Fixes made to the Beta repository are merged to Development by the Snowstorm Team as soon as they are found to be complete.
#* ''Ship'': the Beta is ready as-is.
# Once a build is approved for ship, the Release team does its magic to get the build into the field as a Beta build on the “Second Life Beta Viewer” channel.
# Once a Beta is in the field, we watch for new bugs, crash rate, performance, and other data. If the Beta needs further iteration, we might iterate multiple times on the Beta branch (return to step 4).
# Once the Snowstorm Team decides the Beta is of sufficient quality to ship as an official viewer, the Release team:
## Tags the Beta branch
## Pulls from the tag on Beta to Release
## Tags and builds from the Release repository.
## Releases on the “Second Life Viewer” channel.

Viewer Integration and Release Processes

2010-10-07T15:50:21Z

Q Linden: /* Project */

{{Project Snowstorm Nav}}

This page describes how Viewer development projects are organized, including the Mercurial (hg) repositories, builds, and the integration and release processes through which changes move to get from the developer (either inside or outside Linden Lab) to the Second Life Viewer.

There are three core hg repositories (each repository is in effect a branch; the processes described here do not rely on using the hg branching features within a repository):
* [[#Development|Development]] is the integration trunk
* [[#Beta|Beta]] is used to test and stabilize releases and build beta releases
* [[#Release|Release]] is used to build official stable releases
all three of these repositories are used by both Linden Lab development teams and open source developers; they are accessible at hg.secondlife.com, but only the specific Linden team responsible for each one has commit access to it. Detailed descriptions of each, and the processes for moving changes between them, are below.
__TOC__
<br clear="all"/>

===Development===

[[Image:Development.png|right|caption="Project and Development repositories/branches"]]

'''Location:''' [http://hg.secondlife.com/viewer-development http://hg.secondlife.com/viewer-development]

:'''This is the conceptual ‘trunk’ from which all development, both inside and outside Linden Lab, should be derived.'''

It is built continuously, with the resulting viewers being publicly available (from [[Downloading test builds]] and soon also from the [http://secondlife.com/support/downloads main downloads page]).

Any active viewer development, whether for feature development or bug fixes, pulls from this repository to a [[#Project|Project]] repository, and tracks all changes made in Development as work is done in that Project repository. Code is pulled back to this repository for integration (see [[#Development Integration Criteria|Development Integration Criteria]] below).

Ideally, any build from this repository is a candidate for the next Beta viewer release.

===Project===

'''Location:''' ''determined by the development team, but somewhere at hg.secondlife.com is encouraged''

Any development, whether a single engineer fixing a minor bug or a large team building a major feature, is done in a Project repository that pulls from Development. Large projects will likely have individual repositories pulling from and pushing to their team Project repository; how this is managed and tracks changes made to Development is under the control of the developer(s) on the project.

There may be any number of other repositories created by project teams or developers either inside or outside Linden Lab; these are ''Project'' repositories. The default channel identifier built from these repositories is "Second Life Developer" (projects that plan to make test viewers publicly available, which is encouraged, should change this to a project-specific value in those viewers).

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.

When development is complete '''and the [[#Development Integration Criteria|Development Integration Criteria]] have been satisfied''' changes from a Project repository are moved back to the Development repository. For Linden developers, this can be a push (contact the Snowstorm Team to be configured for write access), or for open source contributors a pull by the Snowstorm Team.

'''Note:''' Developers should consider the viewer-development branch to be a "clean" trunk. It's not "pristine" -- we don't gate checkins through a QA process. But developers should feel very confident BEFORE checking in to viewer-development, because other projects, both internal and external, are pulling from this repository on a daily basis. They should feel confident in doing so, as it may require work to merge the changes. Consequently, '''developers must be willing to support their checkins.'''

''If you are not prepared to respond to bug reports on a high-priority basis all the way through the release process, '''you should not check in'''.''

If a checkin causes excessive instability or breaks customer experience in important ways, it may be reverted and the developer will have to fix the issues and re-integrate. We hope not to have to do this often, but we will make the reversion decision quickly, because reversion usually requires reverting all later checkins as well.

==Development Integration Criteria==

In order to be eligible to be pulled into the Development repository, the changes in a Project repository must satisfy all of the following criteria:

# '''Functionality must have been reviewed and accepted by the Product Owner'''
#: Review is based on the requirements/user stories defined at the beginning of a sprint, and then at the end of a sprint during Acceptance Testing. For Linden development teams, these checks are the normal sprint reviews, not an additional step. For open source developers, the Snowstorm Team will coordinate these reviews with the appropriate Linden reviewers.
# '''Design and code must have been reviewed by competent reviewers.'''
#: In this context, “competent” means appropriate subject matter experts for the code that is modified. Linden development teams determine for themselves who the competent reviewers are; for open source contributions, the Snowstorm Team will determine the appropriate reviews.
#:* If there are changes to code or protocols shared between the viewer and the simulator, those changes must include unit tests that at minimum validate that the behavior before and after the change is compatible. If that is not possible due to the nature of the change, then the change must include documentation on how the interfaces are changed, and the relevant simulator developers must review and approve them (for open source contributions, the Snowstorm Team will coordinate and facilitate these reviews).
# '''There must be a test plan'''
#: The test plan must describe in detail how the modified behavior can be validated and tested. We provide a handy [[Test_Script_Template | test plan template]] to help make this trouble free.
# '''The Project repository must have merged in the latest changes from Development.'''
#: The results must be validated by building viewers for all platforms and doing at least minimal viewer testing. ''Breaking the Development build is considered bad practice and may incur [http://www.ehow.com/about_5108486_karmic-debt.html karmic debt].''
# '''There must be [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf Contribution Agreement]s on file from all contributors to the change if the Project repository contains changes made by non-Lindens.'''

When these criteria have been met, the development team may integrate into the Development repository; see [[How To Submit A Viewer Change]].

==Beta and Release==

To create the Beta and Release Viewers, the changes on the Development repository are moved through the [[#Beta Repository|Beta]] and [[#Release|Release]] repositories following the [[#Beta and Release Process|Beta and Release Process]].

These are continuous processes - soon (preferably within a week) after one set of changes has been moved from Beta to Release, the next Beta cycle is begun by moving the current Development changes to Beta to begin the next cycle. The number of weekly Beta cycles, and thus the frequency of windows for moving from Development to Beta, is determined by the Beta test results.

The targets are that we will have weekly Beta releases, with stable main viewer releases monthly.

[[Image:DevelopmentToRelease.png|right|caption="Development through Beta to Release"]]

===Beta Repository===

'''Location:''' [http://hg.secondlife.com/viewer-beta http://hg.secondlife.com/viewer-beta]

: The Integration and QA team tags Development and pulls from that tag into the Beta repository (since the Beta repository will contain only change sets that are already in Development, this pull does not require any merges).

: Final QA and stabilization are done using builds from the Beta repository; builds from this repository are released weekly on the “Second Life Beta Viewer” channel.

: Any bug fixes on this repository are immediately pulled to the Development repository by the Snowstorm Team.

===Release Repository===

'''Location:''' [http://hg.secondlife.com/viewer-release http://hg.secondlife.com/viewer-release]

: When the Snowstorm Team decides that the Beta branch is ready for release (which we expect to be after 2-4 weeks of testing and stabilization), the Integration team pulls changes from Beta into the Release repository (this is the only path into the Release repository, so this does not require any merges), where it is tagged and built to produce the viewer released on the “Second Life Release” channel.

==Beta and Release Process==

The process by which the Development code is promoted to an official numbered Viewer release is:

# The Integration and QA team adds a beta tag to Development.
# The Release Manager
## Pulls changes from the beta tag on Development to the Beta repository (this should not require any merge).
## Builds branch on Beta
## Creates a release document that includes test plan information and the list of all the changes included in the build (list of JIRAs, etc). Proper attention to detail during development should make this simple.
## Offer build to QA for testing and evaluation
# In QA, the integration test team:
## Executes the set of test plans for all of the changes included
## Performs a general smoke test on overall functionality
## Identifies overall quality and level of risk for release
# The Snowstorm Team evaluates quality, risk and feature set and decides whether or not to release the build as Beta. Options are:
#* ''Fail'': this beta candidate is rejected and the process starts over at some different tag on Development (step 1).
#* ''Fix First'': specific bugs / issues are identified that must be fixed before ship. These bugs are fixed in the Beta repository.
#** Fixes made to the Beta repository are merged to Development by the Snowstorm Team as soon as they are found to be complete.
#* ''Ship'': the Beta is ready as-is.
# Once a build is approved for ship, the Release team does its magic to get the build into the field as a Beta build on the “Second Life Beta Viewer” channel.
# Once a Beta is in the field, we watch for new bugs, crash rate, performance, and other data. If the Beta needs further iteration, we might iterate multiple times on the Beta branch (return to step 4).
# Once the Snowstorm Team decides the Beta is of sufficient quality to ship as an official viewer, the Release team:
## Tags the Beta branch
## Pulls from the tag on Beta to Release
## Tags and builds from the Release repository.
## Releases on the “Second Life Viewer” channel.

Viewer Integration and Release Processes

2010-10-07T15:47:44Z

Q Linden: /* Beta and Release */

{{Project Snowstorm Nav}}

This page describes how Viewer development projects are organized, including the Mercurial (hg) repositories, builds, and the integration and release processes through which changes move to get from the developer (either inside or outside Linden Lab) to the Second Life Viewer.

There are three core hg repositories (each repository is in effect a branch; the processes described here do not rely on using the hg branching features within a repository):
* [[#Development|Development]] is the integration trunk
* [[#Beta|Beta]] is used to test and stabilize releases and build beta releases
* [[#Release|Release]] is used to build official stable releases
all three of these repositories are used by both Linden Lab development teams and open source developers; they are accessible at hg.secondlife.com, but only the specific Linden team responsible for each one has commit access to it. Detailed descriptions of each, and the processes for moving changes between them, are below.
__TOC__
<br clear="all"/>

===Development===

[[Image:Development.png|right|caption="Project and Development repositories/branches"]]

'''Location:''' [http://hg.secondlife.com/viewer-development http://hg.secondlife.com/viewer-development]

:'''This is the conceptual ‘trunk’ from which all development, both inside and outside Linden Lab, should be derived.'''

It is built continuously, with the resulting viewers being publicly available (from [[Downloading test builds]] and soon also from the [http://secondlife.com/support/downloads main downloads page]).

Any active viewer development, whether for feature development or bug fixes, pulls from this repository to a [[#Project|Project]] repository, and tracks all changes made in Development as work is done in that Project repository. Code is pulled back to this repository for integration (see [[#Development Integration Criteria|Development Integration Criteria]] below).

Ideally, any build from this repository is a candidate for the next Beta viewer release.

===Project===

'''Location:''' ''determined by the development team, but somewhere at hg.secondlife.com is encouraged''

Any development, whether a single engineer fixing a minor bug or a large team building a major feature, is done in a Project repository that pulls from Development. Large projects will likely have individual repositories pulling from and pushing to their team Project repository; how this is managed and tracks changes made to Development is under the control of the developer(s) on the project.

There may be any number of other repositories created by project teams or developers either inside or outside Linden Lab; these are ''Project'' repositories. The default channel identifier built from these repositories is "Second Life Developer" (projects that plan to make test viewers publicly available, which is encouraged, should change this to a project-specific value in those viewers).

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.

When development is complete '''and the [[#Development Integration Criteria|Development Integration Criteria]] have been satisfied''' changes from a Project repository are moved back to the Development repository. For Linden developers, this can be a push (contact the Snowstorm Team to be configured for write access), or for open source contributors a pull by the Snowstorm Team.

'''Note:''' Developers should consider the viewer-development branch to be a "clean" trunk. It's not "pristine" -- we don't gate checkins through a QA process. But developers should feel very confident BEFORE checking in to viewer-development, because other projects, both internal and external, are pulling from this repository on a daily basis. They should feel confident in doing so, as it may require work to merge the changes. Consequently, '''developers must be willing to support their checkins.'''

''If you are not prepared to respond to bug reports on a high-priority basis all the way through the release process, '''you should not check in'''.''

==Development Integration Criteria==

In order to be eligible to be pulled into the Development repository, the changes in a Project repository must satisfy all of the following criteria:

# '''Functionality must have been reviewed and accepted by the Product Owner'''
#: Review is based on the requirements/user stories defined at the beginning of a sprint, and then at the end of a sprint during Acceptance Testing. For Linden development teams, these checks are the normal sprint reviews, not an additional step. For open source developers, the Snowstorm Team will coordinate these reviews with the appropriate Linden reviewers.
# '''Design and code must have been reviewed by competent reviewers.'''
#: In this context, “competent” means appropriate subject matter experts for the code that is modified. Linden development teams determine for themselves who the competent reviewers are; for open source contributions, the Snowstorm Team will determine the appropriate reviews.
#:* If there are changes to code or protocols shared between the viewer and the simulator, those changes must include unit tests that at minimum validate that the behavior before and after the change is compatible. If that is not possible due to the nature of the change, then the change must include documentation on how the interfaces are changed, and the relevant simulator developers must review and approve them (for open source contributions, the Snowstorm Team will coordinate and facilitate these reviews).
# '''There must be a test plan'''
#: The test plan must describe in detail how the modified behavior can be validated and tested. We provide a handy [[Test_Script_Template | test plan template]] to help make this trouble free.
# '''The Project repository must have merged in the latest changes from Development.'''
#: The results must be validated by building viewers for all platforms and doing at least minimal viewer testing. ''Breaking the Development build is considered bad practice and may incur [http://www.ehow.com/about_5108486_karmic-debt.html karmic debt].''
# '''There must be [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf Contribution Agreement]s on file from all contributors to the change if the Project repository contains changes made by non-Lindens.'''

When these criteria have been met, the development team may integrate into the Development repository; see [[How To Submit A Viewer Change]].

==Beta and Release==

To create the Beta and Release Viewers, the changes on the Development repository are moved through the [[#Beta Repository|Beta]] and [[#Release|Release]] repositories following the [[#Beta and Release Process|Beta and Release Process]].

These are continuous processes - soon (preferably within a week) after one set of changes has been moved from Beta to Release, the next Beta cycle is begun by moving the current Development changes to Beta to begin the next cycle. The number of weekly Beta cycles, and thus the frequency of windows for moving from Development to Beta, is determined by the Beta test results.

The targets are that we will have weekly Beta releases, with stable main viewer releases monthly.

[[Image:DevelopmentToRelease.png|right|caption="Development through Beta to Release"]]

===Beta Repository===

'''Location:''' [http://hg.secondlife.com/viewer-beta http://hg.secondlife.com/viewer-beta]

: The Integration and QA team tags Development and pulls from that tag into the Beta repository (since the Beta repository will contain only change sets that are already in Development, this pull does not require any merges).

: Final QA and stabilization are done using builds from the Beta repository; builds from this repository are released weekly on the “Second Life Beta Viewer” channel.

: Any bug fixes on this repository are immediately pulled to the Development repository by the Snowstorm Team.

===Release Repository===

'''Location:''' [http://hg.secondlife.com/viewer-release http://hg.secondlife.com/viewer-release]

: When the Snowstorm Team decides that the Beta branch is ready for release (which we expect to be after 2-4 weeks of testing and stabilization), the Integration team pulls changes from Beta into the Release repository (this is the only path into the Release repository, so this does not require any merges), where it is tagged and built to produce the viewer released on the “Second Life Release” channel.

==Beta and Release Process==

The process by which the Development code is promoted to an official numbered Viewer release is:

# The Integration and QA team adds a beta tag to Development.
# The Release Manager
## Pulls changes from the beta tag on Development to the Beta repository (this should not require any merge).
## Builds branch on Beta
## Creates a release document that includes test plan information and the list of all the changes included in the build (list of JIRAs, etc). Proper attention to detail during development should make this simple.
## Offer build to QA for testing and evaluation
# In QA, the integration test team:
## Executes the set of test plans for all of the changes included
## Performs a general smoke test on overall functionality
## Identifies overall quality and level of risk for release
# The Snowstorm Team evaluates quality, risk and feature set and decides whether or not to release the build as Beta. Options are:
#* ''Fail'': this beta candidate is rejected and the process starts over at some different tag on Development (step 1).
#* ''Fix First'': specific bugs / issues are identified that must be fixed before ship. These bugs are fixed in the Beta repository.
#** Fixes made to the Beta repository are merged to Development by the Snowstorm Team as soon as they are found to be complete.
#* ''Ship'': the Beta is ready as-is.
# Once a build is approved for ship, the Release team does its magic to get the build into the field as a Beta build on the “Second Life Beta Viewer” channel.
# Once a Beta is in the field, we watch for new bugs, crash rate, performance, and other data. If the Beta needs further iteration, we might iterate multiple times on the Beta branch (return to step 4).
# Once the Snowstorm Team decides the Beta is of sufficient quality to ship as an official viewer, the Release team:
## Tags the Beta branch
## Pulls from the tag on Beta to Release
## Tags and builds from the Release repository.
## Releases on the “Second Life Viewer” channel.

Viewer Integration and Release Processes

2010-10-07T15:46:44Z

Q Linden: /* Project */

{{Project Snowstorm Nav}}

This page describes how Viewer development projects are organized, including the Mercurial (hg) repositories, builds, and the integration and release processes through which changes move to get from the developer (either inside or outside Linden Lab) to the Second Life Viewer.

There are three core hg repositories (each repository is in effect a branch; the processes described here do not rely on using the hg branching features within a repository):
* [[#Development|Development]] is the integration trunk
* [[#Beta|Beta]] is used to test and stabilize releases and build beta releases
* [[#Release|Release]] is used to build official stable releases
all three of these repositories are used by both Linden Lab development teams and open source developers; they are accessible at hg.secondlife.com, but only the specific Linden team responsible for each one has commit access to it. Detailed descriptions of each, and the processes for moving changes between them, are below.
__TOC__
<br clear="all"/>

===Development===

[[Image:Development.png|right|caption="Project and Development repositories/branches"]]

'''Location:''' [http://hg.secondlife.com/viewer-development http://hg.secondlife.com/viewer-development]

:'''This is the conceptual ‘trunk’ from which all development, both inside and outside Linden Lab, should be derived.'''

It is built continuously, with the resulting viewers being publicly available (from [[Downloading test builds]] and soon also from the [http://secondlife.com/support/downloads main downloads page]).

Any active viewer development, whether for feature development or bug fixes, pulls from this repository to a [[#Project|Project]] repository, and tracks all changes made in Development as work is done in that Project repository. Code is pulled back to this repository for integration (see [[#Development Integration Criteria|Development Integration Criteria]] below).

Ideally, any build from this repository is a candidate for the next Beta viewer release.

===Project===

'''Location:''' ''determined by the development team, but somewhere at hg.secondlife.com is encouraged''

Any development, whether a single engineer fixing a minor bug or a large team building a major feature, is done in a Project repository that pulls from Development. Large projects will likely have individual repositories pulling from and pushing to their team Project repository; how this is managed and tracks changes made to Development is under the control of the developer(s) on the project.

There may be any number of other repositories created by project teams or developers either inside or outside Linden Lab; these are ''Project'' repositories. The default channel identifier built from these repositories is "Second Life Developer" (projects that plan to make test viewers publicly available, which is encouraged, should change this to a project-specific value in those viewers).

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.

When development is complete '''and the [[#Development Integration Criteria|Development Integration Criteria]] have been satisfied''' changes from a Project repository are moved back to the Development repository. For Linden developers, this can be a push (contact the Snowstorm Team to be configured for write access), or for open source contributors a pull by the Snowstorm Team.

'''Note:''' Developers should consider the viewer-development branch to be a "clean" trunk. It's not "pristine" -- we don't gate checkins through a QA process. But developers should feel very confident BEFORE checking in to viewer-development, because other projects, both internal and external, are pulling from this repository on a daily basis. They should feel confident in doing so, as it may require work to merge the changes. Consequently, '''developers must be willing to support their checkins.'''

''If you are not prepared to respond to bug reports on a high-priority basis all the way through the release process, '''you should not check in'''.''

==Development Integration Criteria==

In order to be eligible to be pulled into the Development repository, the changes in a Project repository must satisfy all of the following criteria:

# '''Functionality must have been reviewed and accepted by the Product Owner'''
#: Review is based on the requirements/user stories defined at the beginning of a sprint, and then at the end of a sprint during Acceptance Testing. For Linden development teams, these checks are the normal sprint reviews, not an additional step. For open source developers, the Snowstorm Team will coordinate these reviews with the appropriate Linden reviewers.
# '''Design and code must have been reviewed by competent reviewers.'''
#: In this context, “competent” means appropriate subject matter experts for the code that is modified. Linden development teams determine for themselves who the competent reviewers are; for open source contributions, the Snowstorm Team will determine the appropriate reviews.
#:* If there are changes to code or protocols shared between the viewer and the simulator, those changes must include unit tests that at minimum validate that the behavior before and after the change is compatible. If that is not possible due to the nature of the change, then the change must include documentation on how the interfaces are changed, and the relevant simulator developers must review and approve them (for open source contributions, the Snowstorm Team will coordinate and facilitate these reviews).
# '''There must be a test plan'''
#: The test plan must describe in detail how the modified behavior can be validated and tested. We provide a handy [[Test_Script_Template | test plan template]] to help make this trouble free.
# '''The Project repository must have merged in the latest changes from Development.'''
#: The results must be validated by building viewers for all platforms and doing at least minimal viewer testing. ''Breaking the Development build is considered bad practice and may incur [http://www.ehow.com/about_5108486_karmic-debt.html karmic debt].''
# '''There must be [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf Contribution Agreement]s on file from all contributors to the change if the Project repository contains changes made by non-Lindens.'''

When these criteria have been met, the development team may integrate into the Development repository; see [[How To Submit A Viewer Change]].

==Beta and Release==

To create the Beta and Release Viewers, the changes on the Development repository are moved through the [[#Beta Repository|Beta]] and [[#Release|Release]] repositories following the [[#Beta and Release Process|Beta and Release Process]].

These are continuous processes - soon (preferably within a week) after one set of changes has been moved from Beta to Release, the next Beta cycle is begun by moving the current Development changes to Beta to begin the next cycle. The number of weekly Beta cycles, and thus the frequency of windows for moving from Development to Beta, is determined by the Beta test results.

The targets are that we will have weekly Beta releases, with stable main viewer releases monthly (a set of Beta changes that does not produce a stable build after 3 cycles will trigger a review of whether or not the sources of the instability should be removed).

[[Image:DevelopmentToRelease.png|right|caption="Development through Beta to Release"]]

===Beta Repository===

'''Location:''' [http://hg.secondlife.com/viewer-beta http://hg.secondlife.com/viewer-beta]

: The Integration and QA team tags Development and pulls from that tag into the Beta repository (since the Beta repository will contain only change sets that are already in Development, this pull does not require any merges).

: Final QA and stabilization are done using builds from the Beta repository; builds from this repository are released weekly on the “Second Life Beta Viewer” channel.

: Any bug fixes on this repository are immediately pulled to the Development repository by the Snowstorm Team.

===Release Repository===

'''Location:''' [http://hg.secondlife.com/viewer-release http://hg.secondlife.com/viewer-release]

: When the Snowstorm Team decides that the Beta branch is ready for release (which we expect to be after 2-4 weeks of testing and stabilization), the Integration team pulls changes from Beta into the Release repository (this is the only path into the Release repository, so this does not require any merges), where it is tagged and built to produce the viewer released on the “Second Life Release” channel.

==Beta and Release Process==

The process by which the Development code is promoted to an official numbered Viewer release is:

# The Integration and QA team adds a beta tag to Development.
# The Release Manager
## Pulls changes from the beta tag on Development to the Beta repository (this should not require any merge).
## Builds branch on Beta
## Creates a release document that includes test plan information and the list of all the changes included in the build (list of JIRAs, etc). Proper attention to detail during development should make this simple.
## Offer build to QA for testing and evaluation
# In QA, the integration test team:
## Executes the set of test plans for all of the changes included
## Performs a general smoke test on overall functionality
## Identifies overall quality and level of risk for release
# The Snowstorm Team evaluates quality, risk and feature set and decides whether or not to release the build as Beta. Options are:
#* ''Fail'': this beta candidate is rejected and the process starts over at some different tag on Development (step 1).
#* ''Fix First'': specific bugs / issues are identified that must be fixed before ship. These bugs are fixed in the Beta repository.
#** Fixes made to the Beta repository are merged to Development by the Snowstorm Team as soon as they are found to be complete.
#* ''Ship'': the Beta is ready as-is.
# Once a build is approved for ship, the Release team does its magic to get the build into the field as a Beta build on the “Second Life Beta Viewer” channel.
# Once a Beta is in the field, we watch for new bugs, crash rate, performance, and other data. If the Beta needs further iteration, we might iterate multiple times on the Beta branch (return to step 4).
# Once the Snowstorm Team decides the Beta is of sufficient quality to ship as an official viewer, the Release team:
## Tags the Beta branch
## Pulls from the tag on Beta to Release
## Tags and builds from the Release repository.
## Releases on the “Second Life Viewer” channel.

Viewer Integration and Release Processes

2010-10-07T15:41:10Z

Q Linden: /* Project */

{{Project Snowstorm Nav}}

This page describes how Viewer development projects are organized, including the Mercurial (hg) repositories, builds, and the integration and release processes through which changes move to get from the developer (either inside or outside Linden Lab) to the Second Life Viewer.

There are three core hg repositories (each repository is in effect a branch; the processes described here do not rely on using the hg branching features within a repository):
* [[#Development|Development]] is the integration trunk
* [[#Beta|Beta]] is used to test and stabilize releases and build beta releases
* [[#Release|Release]] is used to build official stable releases
all three of these repositories are used by both Linden Lab development teams and open source developers; they are accessible at hg.secondlife.com, but only the specific Linden team responsible for each one has commit access to it. Detailed descriptions of each, and the processes for moving changes between them, are below.
__TOC__
<br clear="all"/>

===Development===

[[Image:Development.png|right|caption="Project and Development repositories/branches"]]

'''Location:''' [http://hg.secondlife.com/viewer-development http://hg.secondlife.com/viewer-development]

:'''This is the conceptual ‘trunk’ from which all development, both inside and outside Linden Lab, should be derived.'''

It is built continuously, with the resulting viewers being publicly available (from [[Downloading test builds]] and soon also from the [http://secondlife.com/support/downloads main downloads page]).

Any active viewer development, whether for feature development or bug fixes, pulls from this repository to a [[#Project|Project]] repository, and tracks all changes made in Development as work is done in that Project repository. Code is pulled back to this repository for integration (see [[#Development Integration Criteria|Development Integration Criteria]] below).

Ideally, any build from this repository is a candidate for the next Beta viewer release.

===Project===

'''Location:''' ''determined by the development team, but somewhere at hg.secondlife.com is encouraged''

Any development, whether a single engineer fixing a minor bug or a large team building a major feature, is done in a Project repository that pulls from Development. Large projects will likely have individual repositories pulling from and pushing to their team Project repository; how this is managed and tracks changes made to Development is under the control of the developer(s) on the project.

There may be any number of other repositories created by project teams or developers either inside or outside Linden Lab; these are ''Project'' repositories. The default channel identifier built from these repositories is "Second Life Developer" (projects that plan to make test viewers publicly available, which is encouraged, should change this to a project-specific value in those viewers).

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.

When development is complete '''and the [[#Development Integration Criteria|Development Integration Criteria]] have been satisfied''' changes from a Project repository are moved back to the Development repository. For Linden developers, this can be a push (contact the Snowstorm Team to be configured for write access), or for open source contributors a pull by the Snowstorm Team.

'''Note:''' Developers should consider the viewer-development branch to be a "clean" trunk. It's not "pristine" -- we don't gate checkins through a QA process. But developers should feel very confident BEFORE checking in to viewer-development, because other projects, both internal and external, are pulling from this repository on a daily basis. They should feel confident in doing so. Consequently, '''developers must be willing to support their checkins.'''

''If you are not prepared to respond to bug reports on a high-priority basis all the way through the release process, '''you should not check in'''.''

==Development Integration Criteria==

In order to be eligible to be pulled into the Development repository, the changes in a Project repository must satisfy all of the following criteria:

# '''Functionality must have been reviewed and accepted by the Product Owner'''
#: Review is based on the requirements/user stories defined at the beginning of a sprint, and then at the end of a sprint during Acceptance Testing. For Linden development teams, these checks are the normal sprint reviews, not an additional step. For open source developers, the Snowstorm Team will coordinate these reviews with the appropriate Linden reviewers.
# '''Design and code must have been reviewed by competent reviewers.'''
#: In this context, “competent” means appropriate subject matter experts for the code that is modified. Linden development teams determine for themselves who the competent reviewers are; for open source contributions, the Snowstorm Team will determine the appropriate reviews.
#:* If there are changes to code or protocols shared between the viewer and the simulator, those changes must include unit tests that at minimum validate that the behavior before and after the change is compatible. If that is not possible due to the nature of the change, then the change must include documentation on how the interfaces are changed, and the relevant simulator developers must review and approve them (for open source contributions, the Snowstorm Team will coordinate and facilitate these reviews).
# '''There must be a test plan'''
#: The test plan must describe in detail how the modified behavior can be validated and tested. We provide a handy [[Test_Script_Template | test plan template]] to help make this trouble free.
# '''The Project repository must have merged in the latest changes from Development.'''
#: The results must be validated by building viewers for all platforms and doing at least minimal viewer testing. ''Breaking the Development build is considered bad practice and may incur [http://www.ehow.com/about_5108486_karmic-debt.html karmic debt].''
# '''There must be [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf Contribution Agreement]s on file from all contributors to the change if the Project repository contains changes made by non-Lindens.'''

When these criteria have been met, the development team may integrate into the Development repository; see [[How To Submit A Viewer Change]].

==Beta and Release==

To create the Beta and Release Viewers, the changes on the Development repository are moved through the [[#Beta Repository|Beta]] and [[#Release|Release]] repositories following the [[#Beta and Release Process|Beta and Release Process]].

These are continuous processes - soon (preferably within a week) after one set of changes has been moved from Beta to Release, the next Beta cycle is begun by moving the current Development changes to Beta to begin the next cycle. The number of weekly Beta cycles, and thus the frequency of windows for moving from Development to Beta, is determined by the Beta test results.

The targets are that we will have weekly Beta releases, with stable main viewer releases monthly (a set of Beta changes that does not produce a stable build after 3 cycles will trigger a review of whether or not the sources of the instability should be removed).

[[Image:DevelopmentToRelease.png|right|caption="Development through Beta to Release"]]

===Beta Repository===

'''Location:''' [http://hg.secondlife.com/viewer-beta http://hg.secondlife.com/viewer-beta]

: The Integration and QA team tags Development and pulls from that tag into the Beta repository (since the Beta repository will contain only change sets that are already in Development, this pull does not require any merges).

: Final QA and stabilization are done using builds from the Beta repository; builds from this repository are released weekly on the “Second Life Beta Viewer” channel.

: Any bug fixes on this repository are immediately pulled to the Development repository by the Snowstorm Team.

===Release Repository===

'''Location:''' [http://hg.secondlife.com/viewer-release http://hg.secondlife.com/viewer-release]

: When the Snowstorm Team decides that the Beta branch is ready for release (which we expect to be after 2-4 weeks of testing and stabilization), the Integration team pulls changes from Beta into the Release repository (this is the only path into the Release repository, so this does not require any merges), where it is tagged and built to produce the viewer released on the “Second Life Release” channel.

==Beta and Release Process==

The process by which the Development code is promoted to an official numbered Viewer release is:

# The Integration and QA team adds a beta tag to Development.
# The Release Manager
## Pulls changes from the beta tag on Development to the Beta repository (this should not require any merge).
## Builds branch on Beta
## Creates a release document that includes test plan information and the list of all the changes included in the build (list of JIRAs, etc). Proper attention to detail during development should make this simple.
## Offer build to QA for testing and evaluation
# In QA, the integration test team:
## Executes the set of test plans for all of the changes included
## Performs a general smoke test on overall functionality
## Identifies overall quality and level of risk for release
# The Snowstorm Team evaluates quality, risk and feature set and decides whether or not to release the build as Beta. Options are:
#* ''Fail'': this beta candidate is rejected and the process starts over at some different tag on Development (step 1).
#* ''Fix First'': specific bugs / issues are identified that must be fixed before ship. These bugs are fixed in the Beta repository.
#** Fixes made to the Beta repository are merged to Development by the Snowstorm Team as soon as they are found to be complete.
#* ''Ship'': the Beta is ready as-is.
# Once a build is approved for ship, the Release team does its magic to get the build into the field as a Beta build on the “Second Life Beta Viewer” channel.
# Once a Beta is in the field, we watch for new bugs, crash rate, performance, and other data. If the Beta needs further iteration, we might iterate multiple times on the Beta branch (return to step 4).
# Once the Snowstorm Team decides the Beta is of sufficient quality to ship as an official viewer, the Release team:
## Tags the Beta branch
## Pulls from the tag on Beta to Release
## Tags and builds from the Release repository.
## Releases on the “Second Life Viewer” channel.

Open Source Portal

2010-03-22T03:31:29Z

Q Linden: Add repo strategy

{{Multi-lang}}
__NOTOC__
{{Open Source Portal/Links}}

{{Open Source Portal/Featured}}

{|cellspacing="5px"
|valign="top" width="50%"|
<div id="box">

<h2>[[Documentation]]</h2>
<div style="padding: 0.5em">

A lot of the documentation below is geared toward developers. However, many aspects of the system don't require a deep technical background to learn. Much of this is still a work in progress, but since this is a wiki, you can help fill in the blanks!

* '''[[Features]]''' - An overview of the major components of the system as seen from an end user's perspective. Links to specifications, test plans and other documentation can be found here.
* '''[[Viewer architecture]]''' - This is an overview of the viewer from a developer's perspective.
* '''[[Protocol]]''' - in depth documentation of the protocol
* '''[[Extended FAQ]]''' - For questions that don't get covered in {{OSWebsite|faq|alt=the main open source FAQ}}.
* '''[[Viewer source|Viewer Source Code]]'''
* '''[http://secondlifegrid.net/technology-programs/virtual-world-open-source/viewerlicensing Viewer Licensing]'''
* '''[[Server architecture|Server Architecture]]'''
* '''[[Third Party Libraries]]'''
* '''[[Coding Standard]]'''
* '''[[Viewer Roadmap]]'''
* '''[[Linden Lab Repository Strategy]]'''
* '''[[Glossary]]'''

[[Documentation|more...]]

</div></div>
|valign="top" width="50%"|
<div id="box">

<h2>[[Participating|Ways to Participate]]</h2>
<div style="padding: 0.5em">
* [[Developer communication tools|Communication tools (mailing list/IRC/etc)]]
* [[Get source and compile]]
* Complete the [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf Second Life Viewer Contributor Agreement]
* Testing efforts
** [[Snowglobe|Download Snowglobe]]
** [[Bug Reporting 101|File and vet bugs]]
* [[Feature requests|File and refine feature requests]]
* [[Submitting code|Submit code]]
* [[Crash Reports|Inspect crash reports]]
* [[Implementing new features|Implement new features]]
* [[Profiling and Optimization|Profile and Optimize]]
* [[Finding leaks|Find memory leaks]]
* [[Source contributions|See who contributes now]]
* [[Architecture Working Group|Join the Architecture Working Group]]

We want your help to make the Second Life Viewer better! You don't need to know C++ or even programming to help. Some of the toughest jobs in software development have nothing to do with writing code. Just grab [[Downloading test builds|a test build]] and try playing around with it. Let us know what you think on email, on the forum, or IRC. If it's not working for you, try to get help there. If it is working for you, try helping someone who isn't having as much luck as you are. If you run into issues, see if a bug report has been filed, and if it isn't file it. If it has been filed, vote for it, perhaps filling in more detail.

Of course, if you ''are'' a developer, we can use your help. Download the code, and see if you can get it to build. Try your hand at fixing a bug, or extending the software through one of the APIs. There's a ton of ways you can help, and we welcome you regardless of your skill level.

[[Participating|more...]]
</div></div>
|-
|}

[[Category:Portals]]

File:OpenSourceExternal.png

2010-03-22T03:29:53Z

Q Linden: uploaded a new version of "File:OpenSourceExternal.png": Updated with better colors and more annotations.

Diagram of LL's open source repository strategy.

Linden Lab Repository Strategy

2010-03-22T03:27:53Z

Q Linden: First draft of Repository Strategy

This is to document Linden Lab's branching strategy, with respect to its open development as well as its private development. Please see annotations below the image.

<i>Note from Q: as of 21 March 2010 we haven't yet implemented all of this -- some of it is waiting for the final release of Viewer 2.]</i>

[[File:OpenSourceExternal.png]]

A) The "viewer-public" branch is a Linden-internal branch stored in the Mercurial (hg) source control system. It is the upstream (main, topmost) branch for all viewer development at LL. Much of, but not all, viewer development will take place on this branch.

B) The internal viewer-public branch contains some code that cannot be made public. In particular, certain third-party libraries like Kakadu and the Vivox voice library are not exportable. We run a script that automatically excludes these libraries and packages the branch up, and exports it to a Subversion repository called viewer-external.

C) The open source Snowglobe project maintains its own repository. Its upstream repository will be viewer-external. On a frequent basis, it will import changes from viewer-external and incorporate them.

D) Linden Lab maintains an internal branch called viewer-private, which frequently and routinely pulls from viewer-public. It normally contains everything in viewer-public, plus whatever private work Linden does.

E) A Linden software developer creates feature F1 in the viewer-public branch. (Note that in this chart, features appear on each branch when they are first imported to that branch.) F1 will routinely and automatically be exported to viewer-external, and will as a matter of course also appear in Snowglobe.

F) Meanwhile, feature F2 is being developed internally to Linden Lab and not being made public for the time being. It only appears on the viewer-private branch.

G) Routine pull from viewer-public imports F1 into viewer-private.

H) Feature F3 is created by a Snowglobe contributor.

I) Linden Lab decides that it wants to import F3, so it is pulled into viewer-public. Routine export causes it to land in viewer-external and shortly thereafter.

J) Linden plans to release a new viewer, so it explicitly pulls all changes in from viewer-public.

K) Linden then clones viewer-private to make viewer-release. Stabilization and beta are based around the viewer-release branch. (The internal branching strategy is more complex than this, but not necessary for this discussion.)

L) Meanwhile, internal development for a future release can continue on viewer-private. Feature F4 will not be made public until a later release.

M) Once the viewer is ready to release (normally in public beta), viewer-release is merged back into viewer-public, including the private feature F2. F2 then makes its way into viewer-external and Snowglobe

N) The viewer-release branch is released and no further development takes place on that branch until the next release cycle.

O) A Snowglobe feature that Linden Lab doesn't choose to take lives only on the Snowglobe branch.

File:OpenSourceExternal.png

2010-03-22T02:43:16Z

Q Linden: Diagram of LL's open source repository strategy.

Diagram of LL's open source repository strategy.

Channel and Version Requirements

2010-02-17T05:16:30Z

Q Linden: /* Setting a Version Identifier for an Open Source Viewer */

== Setting a Viewer Identifier for an Open Source Viewer ==
A Viewer Identifier is unique to a particular release of a viewer. It is composed of three parts: the Version Name, the Version Variant, and the Version Number. The combination of the Version Name and the Version Variant form the Channel Name.

1. Choose a Version Name
* The default Version Name is "Second Life"
2. Choose a Version Variant. The default variant is "Release"
* The combination of the Name and Variant should be combined to make the Channel Name.
* The default Channel Name is "Second Life Release"
* Other standard Linden Lab Channel Names are "Second Life Release Candidate" and "Second Life First Look [Feature]". Please note that any Channel Name containing "Second Life" is reserved for use by Linden Lab.
* The Channel Name can be any ASCII string. It should not violate [http://secondlife.com/corporate/brand/trademark/ Linden Lab's trademark policy]. We recommend that the Channel Name be the name of the Open Source Viewer.
2. Choose a Version Number
* The Version Number is in the form Major.Minor.Patch.Build
* The Version Number can be any four numbers, separated by periods.
* We recommend using the Major, Minor, and Patch numbers from the most recently merged Linden Lab source code.
** Linden Lab uses an internal number from our source control system for the Build number.
3. Set the Channel and Version in the code
* Edit indra/llcommon/llversionviewer.h
** Modify LL_CHANNEL with the Channel Name
** Modify LL_VERSION_BUILD with the appropriate build number
* Update the Version Number in the following files:
** indra/newview/res/newViewRes.rc - ''"FileVersion" and "ProductVersion" in the Version section''
** indra/newview/Info-SecondLife.plist - ''CFBundleVersion''
** indra/newview/English.lproj/InfoPlist.strings - ''CFBundleShortVersionString''
* Build the code

== Packaging for Distribution ==
* From the indra/newview directory run viewer_manifest.py with the following arguments:
** viewer_manifest.py --login_url=http://your.login.url.com
* See http://wiki.secondlife.com/wiki/Viewer_Manifest for more information on packaging the Viewer

== Updating an Open Source Viewer ==
* Anyone distributing an Open Source version of the Viewer is responsible for messaging updates to residents using that client.
* We recommend using your login url for directing residents to updates.
* Clients not based on the Linden viewer code base should ensure that the XMLRPC login connection sends:
** channel = the channel name, e.g. "My Viewer"
** version = the channel name and a four-part version, e.g. "My Viewer 1.2.3.4"

== Linden Lab Updates ==
* '''Linden Lab updates will not affect non Linden Lab channels.''' This includes optional '''and''' mandatory updates. It is the responsibility of other distributors to ensure that security patches are provided to residents using their client.
* '''NOTE: If Linden Lab determines that a particular client distribution contains security vulnerabilities or exploits, Linden Lab may block that particular version of the client from logging in.'''
* '''NOTE: If Linden Lab introduces a server update that requires a particular capability in order to connect to the server, Viewers that do not include the required capability will be unable to connect to ''regions running that version of the server.''''' It is the intention of Linden Lab to make these required updates infrequent, and to make the Viewer code available well in advance of the server update.

Channel and Version Requirements

2010-02-17T01:35:26Z

Q Linden: /* Setting a Channel and Version for an Open Source Viewer */

== Setting a Version Identifier for an Open Source Viewer ==
A viewer's Version Identifier is unique to a particular release of a viewer. It is composed of three parts: the Version Name, the Version Variant, and the Version Number. The combination of the Version Name and the Version Variant form the Channel Name.

1. Choose a Version Name
* The default Version Name is "Second Life"
2. Choose a Version Variant. The default variant is "Release"
* The combination of the Name and Variant should be combined to make the Channel Name.
* The default Channel Name is "Second Life Release"
* Other standard Linden Lab Channel Names are "Second Life Release Candidate" and "Second Life First Look [Feature]". Please note that any Channel Name containing "Second Life" is reserved for use by Linden Lab.
* The Channel Name can be any ASCII string. It should not violate [http://secondlife.com/corporate/brand/trademark/ Linden Lab's trademark policy]. We recommend that the Channel Name be the name of the Open Source Viewer.
2. Choose a Version Number
* The Version Number is in the form Major.Minor.Patch.Build
* The Version Number can be any four numbers, separated by periods.
* We recommend using the Major, Minor, and Patch numbers from the most recently merged Linden Lab source code.
** Linden Lab uses an internal number from our source control system for the Build number.
3. Set the Channel and Version in the code
* Edit indra/llcommon/llversionviewer.h
** Modify LL_CHANNEL with the Channel Name
** Modify LL_VERSION_BUILD with the appropriate build number
* Update the Version Number in the following files:
** indra/newview/res/newViewRes.rc - ''"FileVersion" and "ProductVersion" in the Version section''
** indra/newview/Info-SecondLife.plist - ''CFBundleVersion''
** indra/newview/English.lproj/InfoPlist.strings - ''CFBundleShortVersionString''
* Build the code

== Packaging for Distribution ==
* From the indra/newview directory run viewer_manifest.py with the following arguments:
** viewer_manifest.py --login_url=http://your.login.url.com
* See http://wiki.secondlife.com/wiki/Viewer_Manifest for more information on packaging the Viewer

== Updating an Open Source Viewer ==
* Anyone distributing an Open Source version of the Viewer is responsible for messaging updates to residents using that client.
* We recommend using your login url for directing residents to updates.
* Clients not based on the Linden viewer code base should ensure that the XMLRPC login connection sends:
** channel = the channel name, e.g. "My Viewer"
** version = the channel name and a four-part version, e.g. "My Viewer 1.2.3.4"

== Linden Lab Updates ==
* '''Linden Lab updates will not affect non Linden Lab channels.''' This includes optional '''and''' mandatory updates. It is the responsibility of other distributors to ensure that security patches are provided to residents using their client.
* '''NOTE: If Linden Lab determines that a particular client distribution contains security vulnerabilities or exploits, Linden Lab may block that particular version of the client from logging in.'''
* '''NOTE: If Linden Lab introduces a server update that requires a particular capability in order to connect to the server, Viewers that do not include the required capability will be unable to connect to ''regions running that version of the server.''''' It is the intention of Linden Lab to make these required updates infrequent, and to make the Viewer code available well in advance of the server update.

Channel and Version Requirements

2010-02-15T18:46:18Z

Q Linden: /* Setting a Channel and Version for an Open Source Viewer */

== Setting a Channel and Version for an Open Source Viewer ==
1. Choose a channel name
* The default channel name is "Second Life Release"
* Other standard Linden Lab channel names are "Second Life Release Candidate" and "Second Life First Look [Feature]". Please note that any channel name containing "Second Life" is reserved for use by Linden Lab.
* The channel name can be any ASCII string. It should not violate [http://secondlife.com/corporate/brand/trademark/ Linden Lab's trademark policy]. We recommend that the channel name be the name of the Open Source Viewer.
2. Choose a version number
* The version number is in the form Major.Minor.Patch.Build
* The version number can be any four numbers, separated by periods.
* We recommend using the Major, Minor, and Patch numbers from the most recently merged Linden Lab source code.
** Linden Lab uses an internal number from our source control system for the Build number.
3. Set the Channel and Version in the code
* Edit indra/llcommon/llversionviewer.h
** Modify LL_CHANNEL with the Channel Name
** Modify LL_VERSION_BUILD with the appropriate build number
* Update the version number in the following files:
** indra/newview/res/newViewRes.rc - ''"FileVersion" and "ProductVersion" in the Version section''
** indra/newview/Info-SecondLife.plist - ''CFBundleVersion''
** indra/newview/English.lproj/InfoPlist.strings - ''CFBundleShortVersionString''
* Build the code

== Packaging for Distribution ==
* From the indra/newview directory run viewer_manifest.py with the following arguments:
** viewer_manifest.py --login_url=http://your.login.url.com
* See http://wiki.secondlife.com/wiki/Viewer_Manifest for more information on packaging the Viewer

== Updating an Open Source Viewer ==
* Anyone distributing an Open Source version of the Viewer is responsible for messaging updates to residents using that client.
* We recommend using your login url for directing residents to updates.
* Clients not based on the Linden viewer code base should ensure that the XMLRPC login connection sends:
** channel = the channel name, e.g. "My Viewer"
** version = the channel name and a four-part version, e.g. "My Viewer 1.2.3.4"

== Linden Lab Updates ==
* '''Linden Lab updates will not affect non Linden Lab channels.''' This includes optional '''and''' mandatory updates. It is the responsibility of other distributors to ensure that security patches are provided to residents using their client.
* '''NOTE: If Linden Lab determines that a particular client distribution contains security vulnerabilities or exploits, Linden Lab may block that particular version of the client from logging in.'''
* '''NOTE: If Linden Lab introduces a server update that requires a particular capability in order to connect to the server, Viewers that do not include the required capability will be unable to connect to ''regions running that version of the server.''''' It is the intention of Linden Lab to make these required updates infrequent, and to make the Viewer code available well in advance of the server update.

SLDev Open Source Viewer

2009-05-01T14:54:44Z

Q Linden: New page: =What is the SLDev Open Source Viewer?= See [https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts Philip's blog post] for the initial announc...

=What is the SLDev Open Source Viewer?=

See [https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts Philip's blog post] for the initial announcement.

Merov posted on SLDev:

''We do hope that most of the innovations battle-tested here will
eventually make it to the official viewer codebase but things that are
clearly not mainstream enough or not very popular with this community
simply won't make it there and that's ok. People will still be able to
get those features in the "Second Life OSS" download though.''

This document is an edited version of some of Merov's other comments on the SLDev list combined with an edited outline originally by Mike Monkowski.

=How do I contribute to it?=
==Talk to the mailing list==

First, you might want to have a discussion about your idea. Chat on the SLDev mailing list. Create a JIRA and see if others agree with you. Refine the JIRA to get the idea clearly defined.

==Write your code==

Writing code isn't just writing the lines of C++. It's also documenting the code, designing a test plan, doing the actual testing, and making sure it works in a variety of situations.

When you think it's solid, you should create a patch file (using a diff tool like svn diff) and attach the patch to the JIRA. You should attach the test plan in the JIRA, either directly in a comment, an attached document, or a nonvolatile link to it on the web.

==Get your code reviewed==

You should then ask in the JIRA, and possibly on SLDev, for comments on the code and for people to help by trying out the test plan. Give people time (at least a day, maybe quite a bit more depending on the complexity of your submission and the timing) to evaluate it and comment.

Keep in mind that a positive, engaged attitude on SLDev and in JIRA is likely to garner more support than a more negative approach.

==Get it committed to the repository==

It's like almost any other FLOSS project: there is a group of
*committers* that do have commit privileges to the svn tree. The big
difference with the "old LL way of doing things" is that this group of
committers has Lindens *and* non-Lindens. Engage folks on SLDev to get support: are people interested by
the feature, is this a worthy issue to fix?

If there is community
support and a good review of the code from committers, the patch will
be taken in and committed by one of the committers. Eventually, if your
contributions are significant and in line with the project,
other committers might propose that you to become a committer himself. The
committers group grows by internal recommendations only.

If someone objects (and if our community is alive, there *will* be
someone to object...), we debate and try to reach a consensus on this
list. If there's a really contentious decision to be made (split
debate), Philip, our BDFL (Benevolent Dictator For Life), will weight
in and make the decision.

==Track it through the merge process==

Some contributions may merge back to the official viewer someday. That
will be up to the LL
viewer team to cherry pick and merge patches/commits separately.

This is not easy to do. Making this more manageable is one
of the big reason for the push to hg (mercurial) which does make
merges from various sources much more easier than svn.

Open Source Meeting/2009-04-30

2009-04-30T23:40:10Z

Q Linden:

* [14:02] [[User:Q Linden|Q Linden]]: Ok, while Merov is deciding who to sit on, here's the agenda for today:
* [14:02] [[User:Q Linden|Q Linden]]: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda#Agenda
* [14:02] [[User:Yann Dufaux|Yann Dufaux]]: i have look for svn commit, on wiki whats this? :)
* [14:03] [[User:Yann Dufaux|Yann Dufaux]]: hey Merov :)
* [14:03] [[User:Merov Linden|Merov Linden]]: salut Yann
* [14:03] [[User:Q Linden|Q Linden]]: Usual warning, anything you say here will be posted on wiki
* [14:03] [[User:Yann Dufaux|Yann Dufaux]]: comme promis j,suis ici :)
* [14:03] [[User:Q Linden|Q Linden]]: yann, don't understand the question?
* [14:03] [[User:Garmin Kawaguichi|Garmin Kawaguichi]]: :))
* [14:04] [[User:Yann Dufaux|Yann Dufaux]]: [http://wiki.secondlife.com/wiki/Special:Search?search=SVN+commit&go=Go]
* [14:04] [[User:Merov Linden|Merov Linden]]: super, let's switch to English though in the local chat :)
* [14:04] [[User:Yann Dufaux|Yann Dufaux]]: yes, no problem for me :)
* [14:04] [[User:Soft Linden|Soft Linden]]: Mon bateau de vol plan est plein des anguilles.
* [14:04] [[User:Yann Dufaux|Yann Dufaux]]: uh?
* [14:04] [[User:Techwolf Lupindo|Techwolf Lupindo]]: Translaters suck for the most part.
* [14:05] [[User:Garmin Kawaguichi|Garmin Kawaguichi]]: :=)))
* [14:05] [[User:Soft Linden|Soft Linden]]: "My hoverboat is full of eels."
* [14:05] [[User:Q Linden|Q Linden]]: yann, if you need instructions on SVN
* [14:05] [[User:Yann Dufaux|Yann Dufaux]]: nice try :))
* [14:05] [[User:Yann Dufaux|Yann Dufaux]]: Hehehe :)
* [14:05] [[User:Q Linden|Q Linden]]: look in global google
* [14:06] [[User:Q Linden|Q Linden]]: ok, to the agenda, please
* [14:06] [[User:Q Linden|Q Linden]]: Item 1: 1.23 RC0 -- comments, questions?
* [14:06] [[User:Techwolf Lupindo|Techwolf Lupindo]]: I'me still working on getting my ebuild updated to RC0 so I can test it.
* [14:06] [[User:Elanthius Flagstaff|Elanthius Flagstaff]]: People are very angry about the eyebrows thing
* [14:06] [[User:Yann Dufaux|Yann Dufaux]]: well nice adding, but i observ some bugs with picture:)
* [14:07] [[User:Soft Linden|Soft Linden]]: Aimee was kind enough to verify that the 1.23 export is indeed building on a never-touched-by-Linden system. So it's a good time to dive in.
* [14:07] [[User:Yann Dufaux|Yann Dufaux]]: [http://jira.secondlife.com/browse/VWR-13045]
* [14:07] [[User:Aimee Trescothick|Aimee Trescothick]]: :)
* [14:07] [[User:Q Linden|Q Linden]]: Eyebrows thing: yes, we know
* [14:07] [[User:Q Linden|Q Linden]]: We attempted to fix one set of inconsistencies, but many people depend on those inconsistencies, so we're going to revert it for RC1
* [14:07] [[User:Yann Dufaux|Yann Dufaux]]: i have added some picture with this bugs, and i notice the same after update
* [14:08] [[User:Yann Dufaux|Yann Dufaux]]: i test on the beta grid, and i don't have this result
* [14:08] [[User:Aimee Trescothick|Aimee Trescothick]]: moral if this story is, always check the consistency when you're baking
* [14:08] [[User:Aimee Trescothick|Aimee Trescothick]]: *of
* [14:09] [[User:Yann Dufaux|Yann Dufaux]]: hi dirk :)
* [14:09] [[User:Dirk Talamasca|Dirk Talamasca]]: Hi Hi Yann
* [14:09] [[User:Q Linden|Q Linden]]: thanks, yann. we'll look at that
* [14:10] [[User:Thickbrick Sleaford|Thickbrick Sleaford]]: Does Restore to Last Position exists in RC0 the same as http-texture? If so, I expect lots of lost inventory...
* [14:10] [[User:Yann Dufaux|Yann Dufaux]]: Q, your welcome, and i think the bugs with cloting strech and color on skin is back ..
* [14:10] [[User:Q Linden|Q Linden]]: Thickbrick, wehre is it in httptexture?
* [14:10] [[User:Thickbrick Sleaford|Thickbrick Sleaford]]: right where Wear used to be
* [14:10] [[User:Aimee Trescothick|Aimee Trescothick]]: it came in from 1.23 I believe
* [14:10] [[User:Thickbrick Sleaford|Thickbrick Sleaford]]: in the inventory right click menu
* [14:11] [[User:Q Linden|Q Linden]]: yes, it's in 1.23
* [14:11] [[User:Soft Linden|Soft Linden]]: What's the "restore to last position" issue?
* [14:11] [[User:Soft Linden|Soft Linden]]: Oh, menu replacement
* [14:12] [[User:Aimee Trescothick|Aimee Trescothick]]: I'm guessing you restore it to last position, but then don't know where the last position was
* [14:12] [[User:Thickbrick Sleaford|Thickbrick Sleaford]]: yes, like for huds and shoes
* [14:12] [[User:Aimee Trescothick|Aimee Trescothick]]: maybe that should require confirmation for no copy stuff or something
* [14:13] [[User:Dirk Talamasca|Dirk Talamasca]]: yeah you could be on the ground and rez a chair up in the wild blue yonder then spend an hour hunting for it
* [14:13] [[User:Q Linden|Q Linden]]: ok, well, we operate best if there's a JIRA on it
* [14:13] [[User:Thickbrick Sleaford|Thickbrick Sleaford]]: I lost a hud that will probably be returned to me some day that way
* [14:13] [[User:Thickbrick Sleaford|Thickbrick Sleaford]]: I'll hunt for a jura after the meeting
* [14:13] [[User:Thickbrick Sleaford|Thickbrick Sleaford]]: *jira
* [14:13] [[User:Yann Dufaux|Yann Dufaux]]: Q, the actual jiras for this can be reopne, or i need to make a new jiras?
* [14:14] [[User:Yann Dufaux|Yann Dufaux]]: reopen* sorry
* [14:14] [[User:Q Linden|Q Linden]]: yann, if a problem has returned, you can reopen a jira ... as long as it's really the same problem
* [14:15] [[User:Yann Dufaux|Yann Dufaux]]: okey, ty! :)
* [14:15] [[User:Q Linden|Q Linden]]: anything else?
* [14:16] [[User:Q Linden|Q Linden]]: Ok, VWR-6198 -- can it get some love?
* [14:16] [[User:Mm Alder|Mm Alder]]: It just celebrated a birthday!
* [14:17] [[User:Q Linden|Q Linden]]: So, mm, this got stalled internally over a licensing issue, but my not-a-lawyer take on it is that it should be OK. I'll ask Rob to follow up when he gets back.
* [14:17] [[User:Q Linden|Q Linden]]: I really hope it could be solved.
* [14:17] [[User:Soft Linden|Soft Linden]]: Or at the very least, we should be able to post the souce for our part, and direct people on where to get the code with the sticky license.
* [14:17] [[User:Mm Alder|Mm Alder]]: It would have been nice if someone responded on the JIRA.
* [14:18] [[User:Soft Linden|Soft Linden]]: Want me to drop a reminder on the internal, Q?
* [14:18] [[User:Q Linden|Q Linden]]: Yes, please
* [14:18] [[User:Mm Alder|Mm Alder]]: Posting whatever you have would be very good.
* [14:19] [[User:Q Linden|Q Linden]]: mm, give us a week, but let's cycle this to next week's agenda once Rob's back.
* [14:19] [[User:Mm Alder|Mm Alder]]: It's the XML format I'm after. I don't want to run it.
* [14:19] [[User:Mm Alder|Mm Alder]]: OK
* [14:19] [[User:Q Linden|Q Linden]]: oh? That might be easier
* [14:20] [[User:Q Linden|Q Linden]]: Next: Can we get better documentation on the open source viewer project (aka http-texture)? Is there anyone other than me who would be interested in open code reviews for this project? Mm Alder
* [14:20] [[User:Q Linden|Q Linden]]: mm, can you explain? How's that different from what we've been discussing on sldev?
* [14:21] [[User:Mm Alder|Mm Alder]]: Permanent documentation is a good thing. Better than a mailing list archive.
* [14:21] [[User:Mm Alder|Mm Alder]]: But even SLDEV doesn't have the answers.
* [14:22] [[User:Mm Alder|Mm Alder]]: Is this new open source viewer (aka http-texture) his new open source portal or is it a sneaky underhanded backdoor to infiltrate the viewer codebase?
* [14:22] [[User:Aimee Trescothick|Aimee Trescothick]]: LOL
* [14:23] [[User:Q Linden|Q Linden]]: uhhh.... it's the new non-sneaky frontdoor?
* [14:23] [[User:Aimee Trescothick|Aimee Trescothick]]: get the lock picks
* [14:23] [[User:Soft Linden|Soft Linden]]: It's not a sneaky back door.
* [14:23] [[User:Soft Linden|Soft Linden]]: And something making it into the open source viewer doesn't guarantee that it goes into the main viewer. It's still subject to the same scrutiny as before when it makes that jump.
* [14:23] [[User:Morgaine Dinova|Morgaine Dinova]]: Can we please have proper documentation on the back doors? ;-)))
* [14:24] [[User:Q Linden|Q Linden]]: just grep the source for xyzzy
* [14:24] [[User:Morgaine Dinova|Morgaine Dinova]]: chuckles
* [14:24] [[User:Soft Linden|Soft Linden]]: Ha!
* [14:24] [[User:Merov Linden|Merov Linden]]: http-texture is an active open source collaboration where Lindens *and* outside contributors work together
* [14:24] [[User:Merov Linden|Merov Linden]]: that's really the charter Philip gave us
* [14:24] [[User:Mm Alder|Mm Alder]]: OK, let's say Joe Sldev (I think the name is Serbian) has a great idea that he want's to get into the SL viewer.
* [14:24] [[User:Mm Alder|Mm Alder]]: He has a PJIRA entry with a patch file. How does that make its way to the SVN project? Does he have to worry about getting it into the SVN branch? Are there gatekeepers along the way? What if someone objects? Do we end up with SVN wars like Wiki wars?
* [14:25] [[User:Merov Linden|Merov Linden]]: I haven't had time to answer that one in details Alder
* [14:25] [[User:Soft Linden|Soft Linden]]: the only back door contribution method still involves bottles of scotch brought directly to the San Francisco, Brighton, Boston and Chicago offices.
* [14:25] [[User:Merov Linden|Merov Linden]]: was in meetings since that mail arrived
* [14:25] [[User:Q Linden|Q Linden]]: Simultaneously
* [14:25] [[User:Morgaine Dinova|Morgaine Dinova]]: Is there a wiki page for Philip's viewer, something with links off to the relevant data?
* [14:25] [[User:Soft Linden|Soft Linden]]: yus :>
* [14:25] [[User:Melinda Latynina|Melinda Latynina]]: this is all still very much a work-in-progress, no? I.E. can't have permanant rules & regulations yet, but the good news is that we all get to help drive the direction.
* [14:25] [[User:Morgaine Dinova|Morgaine Dinova]]: checks
* [14:26] [[User:Q Linden|Q Linden]]: Seriously, though, I think that we're moving toward "post a patch, post on SLDev for feedback, react to feedback, eventually check in patch."
* [14:26] [[User:Mm Alder|Mm Alder]]: But none of the policy seems to be written down yet.
* [14:26] [[User:Merov Linden|Merov Linden]]: when Philip was there remember , he didn't want to start the project with a long list of "processes" and "regulation"
* [14:27] [[User:Mm Alder|Mm Alder]]: I'm trying to get in literally a one bit change and I'm finding it very difficult.
* [14:27] [[User:Merov Linden|Merov Linden]]: so his idea was more: proposes something on list and we get from there
* [14:27] [[User:Q Linden|Q Linden]]: mm, you mean lip flap?
* [14:27] [[User:Merov Linden|Merov Linden]]: which one Alder?
* [14:27] [[User:Soft Linden|Soft Linden]]: I wouldn't anticipate that subsequent contributions have the overhead of the first dozen.
* [14:27] [[User:Mm Alder|Mm Alder]]: yes
* [14:28] [[User:Morgaine Dinova|Morgaine Dinova]]: Well in theory Philip's branch was intended to make it *easier* to commit changes. If it's still not easy enough, maybe a third LL VWR project is needed :P
* [14:28] [[User:Morgaine Dinova|Morgaine Dinova]]: laughs
* [14:28] [[User:Soft Linden|Soft Linden]]: :)
* [14:28] [[User:Q Linden|Q Linden]]: facepalms
* [14:28] [[User:Soft Linden|Soft Linden]]: Hold off on assuming that you know what the final process looks like until a few patches have gone through.
* [14:29] [[User:Merov Linden|Merov Linden]]: Your contribution has been voted "in" Alder
* [14:29] [[User:Mm Alder|Mm Alder]]: Does it have to be this hard?
* [14:29] [[User:Q Linden|Q Linden]]: we sure hope not
* [14:30] [[User:Q Linden|Q Linden]]: but we're still working it out...and everyone is still tentative
* [14:30] [[User:Robin Cornelius|Robin Cornelius]]: i was very suprised by the reaction to such a simple change
* [14:30] [[User:Soft Linden|Soft Linden]]: Anything touching on voice invites an awful lot of friction. I don't fully understand it myself.
* [14:30] [[User:Squirrel Wood|Squirrel Wood]]: At least we know that one contribution method still involves bottles of scotch brought directly to the San Francisco, Brighton, Boston and Chicago offices. ^^
* [14:30] [[User:Q Linden|Q Linden]]: maybe we're just used to the surprise
* [14:30] [[User:Melinda Latynina|Melinda Latynina]]: is not tentative :-)
* [14:31] [[User:Robin Cornelius|Robin Cornelius]]: i would have 2nd my self but i've never evern seen teh code running as i almost never use voice, so i don't feel i can approve any code i can't test my self
* [14:31] [[User:Squirrel Wood|Squirrel Wood]]: Or so I've heard.
* [14:31] [[User:Mm Alder|Mm Alder]]: So when I want to contribute my next patch which has popup menus and writes files, what then?
* [14:31] [[User:Merov Linden|Merov Linden]]: Alder: not everybody has commit privileges so it's assigned to someone who has
* [14:31] [[User:Morgaine Dinova|Morgaine Dinova]]: Might have been a good time to move to Hg actually.
* [14:31] [[User:Robin Cornelius|Robin Cornelius]]: MM if its an area i know, then i would be happy to look
* [14:31] [[User:Merov Linden|Merov Linden]]: this someone is me now
* [14:31] [[User:Aimee Trescothick|Aimee Trescothick]]: well Hg is there now at least :)
* [14:31] [[User:Soft Linden|Soft Linden]]: Hg is coming. And we did talk about using it for this, but didn't want yet another thing that had to be working before launching.
* [14:32] [[User:Merov Linden|Merov Linden]]: so you can kick my butt now if that doesn't move forward
* [14:32] [[User:Q Linden|Q Linden]]: morgaine, we're almost all the way to hg
* [14:32] [[User:Morgaine Dinova|Morgaine Dinova]]: Woohoo!
* [14:32] [[User:Q Linden|Q Linden]]: can't happen fast enough for me. :)
* [14:32] [[User:Mm Alder|Mm Alder]]: Hg?
* [14:32] [[User:Q Linden|Q Linden]]: Mercurial source control
* [14:32] [[User:Aimee Trescothick|Aimee Trescothick]]: [http://bitbucket.org/lindenlab/http-texture/]
* [14:33] [[User:Q Linden|Q Linden]]: OK? "I wonder if someone could give a brief update on the status of plugin explorations." -- JB Kraft
* [14:33] [[User:JB Kraft|JB Kraft]]: i found some discussion on the dev list from a couple of years ago, soft did some work on this i belive. just wondered if it stalled and why and what spark might ignite it again, if any?
* [14:33] [[User:Robin Cornelius|Robin Cornelius]]: people have been contacting me recently about this as well
* [14:33] [[User:Q Linden|Q Linden]]: JB, it's smouldering as we speak
* [14:34] [[User:Morgaine Dinova|Morgaine Dinova]]: Mm: [http://www.selenic.com/mercurial/wiki/] , [http://en.wikipedia.org/wiki/Mercurial_(software)]
* [14:34] [[User:Soft Linden|Soft Linden]]: I sooooo want plugins. :<
* [14:34] [[User:Merov Linden|Merov Linden]]: me too
* [14:34] [[User:Soft Linden|Soft Linden]]: oops gesture
* [14:34] [[User:JB Kraft|JB Kraft]]: yeah, it would be nice :) is there anything form outside that might push it along?
* [14:34] [[User:Q Linden|Q Linden]]: the stall has been that this is one case where the hack is the true enemy of a good design, because we'll be stuck with it forever (*cough*skin layers*cough*)
* [14:35] [[User:Merov Linden|Merov Linden]]: it's not easy to get it right from the host standpoint
* [14:35] [[User:Morgaine Dinova|Morgaine Dinova]]: Plugins in what? In viewer? If anyone's working on that, I'd love to talk to them, since that's my goal for Imprudence.
* [14:35] [[User:Q Linden|Q Linden]]: so we've been working on an event system that would act as the transport of information between plugins
* [14:35] [[User:JB Kraft|JB Kraft]]: ah ok, that is good news
* [14:35] [[User:Q Linden|Q Linden]]: You can see a preview of some of these ideas in the Notifications event API, but that's not complete yet
* [14:36] [[User:Merov Linden|Merov Linden]]: Q: using IPC?
* [14:36] [[User:Melinda Latynina|Melinda Latynina]]: JB: weren't you looking into a plug-in archetecture for text editors?
* [14:36] [[User:Q Linden|Q Linden]]: boost signals
* [14:36] [[User:JB Kraft|JB Kraft]]: yes, the editor is one of my pet projects and that was a part of it. thats why i wondered :)
* [14:37] [[User:Q Linden|Q Linden]]: and...not coincidentally, we actually wanted to talk about script editor improvements today
* [14:37] [[User:Q Linden|Q Linden]]: we thought it would be a good time to start the design discussion on sldev/here
* [14:38] [[User:Melinda Latynina|Melinda Latynina]]: i believe we can have plug-ins in multiple places and deal with the merits and weaknesses of each rather than try to find a one-size-fits-all
* [14:38] [[User:Q Linden|Q Linden]]: projects like [http://web.mit.edu/~eric_r/Public/S4SL/] (scratch for second life) need a plugin editor
* [14:38] [[User:JB Kraft|JB Kraft]]: excellent! i have a bunch of patches for the editor but kind of got discouraged with process tbh. it would be great to hack out a path for it :)
* [14:39] [[User:Morgaine Dinova|Morgaine Dinova]]: [http://imprudenceviewer.org/w/images/4/48/Plugin_system_flow_APIs.png] --- that gives a general view of our plugin architecture for Imprudence.
* [14:40] [[User:Squirrel Wood|Squirrel Wood]]: improvements... one simple improvements would be to allow bulk uploads of .txt and .lsl files ?
* [14:40] [[User:Q Linden|Q Linden]]: yes, morgaine...but some of the details of how the sockets communicate and what the control model is are key to getting this right
* [14:40] [[User:Q Linden|Q Linden]]: so I like that chart, but I want more. :)
* [14:40] [[User:Morgaine Dinova|Morgaine Dinova]]: This is the general forum, everything marked as [Plugins
* [14:40] [[User:Morgaine Dinova|Morgaine Dinova]]: [http://imprudenceviewer.org/forums/viewforum.php?f=7&sid=d27038a45f73559be80b8cda33c3cc5b]
* [14:41] [[User:JB Kraft|JB Kraft]]: squirrel, i have a patch on the jira that load and saves from the editor to disc, kudgly at the mo but it works for me
* [14:41] [[User:Morgaine Dinova|Morgaine Dinova]]: Q: yep, the internal viewer API is central, and clearly needs to be event-based.
* [14:41] [[User:Robin Cornelius|Robin Cornelius]]: JB i think squirrel whats the File->Uload->Bulk to support text for notecards and scripts (with approprate expension)
* [14:42] [[User:JB Kraft|JB Kraft]]: ah, right
* [14:42] [[User:Robin Cornelius|Robin Cornelius]]: pretty simple to do actually
* [14:42] [[User:Squirrel Wood|Squirrel Wood]]: there is a jira somewhere for it even ^^
* [14:42] [[User:Robin Cornelius|Robin Cornelius]]: but loading and saving from the text editor is a godsend
* [14:43] [[User:Morgaine Dinova|Morgaine Dinova]]: Q: are you thinking as we are then, that decoupling plugins from the viewer monolith is the key to sanity?
* [14:43] [[User:Q Linden|Q Linden]]: yes
* [14:43] [[User:Q Linden|Q Linden]]: *I* am
* [14:43] [[User:Morgaine Dinova|Morgaine Dinova]]: Great to hear! :-)
* [14:43] [[User:JB Kraft|JB Kraft]]: https://jira.secondlife.com/browse/VWR-5206
* [14:43] [[User:Q Linden|Q Linden]]: And we're moving in that direction...but honestly, it's a multi-year effort
* [14:43] [[User:Morgaine Dinova|Morgaine Dinova]]: Yep. not easy
* [14:43] [[User:Q Linden|Q Linden]]: A big chunk of our work this year is going to enabling that decoupling
* [14:43] [[User:JB Kraft|JB Kraft]]: thats awesome Q!
* [14:44] [[User:Mm Alder|Mm Alder]]: Please don't forget, "Is there anyone other than me who would be interested in open code reviews for this project? Mm Alder 15:57, 30 April 2009 (UTC) "
* [14:44] [[User:Morgaine Dinova|Morgaine Dinova]]: Just binding in a language would be pretty trivial, bit the wrong thing to do, if there is to be any hope of stability and portability.
* [14:44] [[User:Q Linden|Q Linden]]: right, morgaine; whatever we do, we do forever
* [14:45] [[User:Q Linden|Q Linden]]: so we really want to make sure it has a future
* [14:45] [[User:Q Linden|Q Linden]]: (while not living in analysis paralysis forever either!)
* [14:45] [[User:Morgaine Dinova|Morgaine Dinova]]: Yeah
* [14:45] [[User:Robin Cornelius|Robin Cornelius]]: mm, i'm fully up for open code reviews
* [14:45] [[User:Aimee Trescothick|Aimee Trescothick]]: yes
* [14:46] [[User:Squirrel Wood|Squirrel Wood]]: JB: https://jira.secondlife.com/browse/VWR-7959
* [14:46] [[User:Q Linden|Q Linden]]: mm, that's what I thought the idea was behind posting the patch on jira before applying it
* [14:46] [[User:Q Linden|Q Linden]]: is that not the same thing you're saying?
* [14:46] [[User:Morgaine Dinova|Morgaine Dinova]]: Q: if anything happens on Imprudence plugins (and that's not certain), I'd appreciate your feedback.
* [14:46] [[User:Mm Alder|Mm Alder]]: No, I mean a code presentation in-world where people can ask questions and learn a bit about what the code does.
* [14:47] [[User:Robin Cornelius|Robin Cornelius]]: sounds like what Phillip was taking about
* [14:47] [[User:Merov Linden|Merov Linden]]: Alder: that's more of a "design review" then (as in "code design")
* [14:47] [[User:Mm Alder|Mm Alder]]: Philip was talking about it, but then ....
* [14:47] [[User:Q Linden|Q Linden]]: The more of that we see, the better....but I'm not sure it needs to be a required part of every submission.
* [14:48] [[User:Q Linden|Q Linden]]: depends a lot on the scope of what's happening, I guess
* [14:48] [[User:Q Linden|Q Linden]]: I think a valid response to "hey, I've just attached a patch" would be "I'd like to have a conversation about this inworld."
* [14:48] [[User:Mm Alder|Mm Alder]]: If I were to ask someone to review my patch for editing morphs, I would be surprised if anyone would understand it without explanation.
* [14:48] [[User:Merov Linden|Merov Linden]]: Alder: are you talking about general part of the viewer architecture or specific submission?
* [14:49] [[User:Mm Alder|Mm Alder]]: Specific submission. But you'd also learn about the viewer in the process just by listening.
* [14:49] [[User:Merov Linden|Merov Linden]]: understood
* [14:49] [[User:Morgaine Dinova|Morgaine Dinova]]: Instead of conversations in-world, how about insisting on Doxygen-style documentation in patches instead? That can be anything, including design documentation.
* [14:49] [[User:Mm Alder|Mm Alder]]: I can ask Doxygen a question. :-)
* [14:50] [[User:JB Kraft|JB Kraft]]: +1 morgaine
* [14:51] [[User:Merov Linden|Merov Linden]]: well, on one instance, (VWR-12748 submitted by Robin) I reviewed and proposed a modified patch, she modified, etc...
* [14:51] [[User:Mm Alder|Mm Alder]]: I love Doxygen, but it can't replace a human who understands the code.
* [14:51] [[User:Merov Linden|Merov Linden]]: so the code review was done in the JIRA through a back and forth of commented patches
* [14:51] [[User:Morgaine Dinova|Morgaine Dinova]]: Mm: hehe, well Doxygen only reflects what devs put it ... but if there's a long chuck of code without any human-added Doxygen headers, then I think it's reasonable to ask "Hey, how about some explanatory text for this?" :-)
* [14:52] [[User:Q Linden|Q Linden]]: me too
* [14:52] [[User:Merov Linden|Merov Linden]]: I guess IW presentation would be good for general part of the architecture or really hairy patches
* [14:52] [[User:Q Linden|Q Linden]]: that's a part of a good code review -- it shouldn't be just "does it work" but "is it maintainable"
* [14:53] [[User:Melinda Latynina|Melinda Latynina]]: likes the idea of IW code/design reviews
* [14:54] [[User:Q Linden|Q Linden]]: So Aimee asks "Procedure for getting supporting artwork in before committing a patch to http-texture? i.e. VWR-12748[c
* [14:54] [[User:Merov Linden|Merov Linden]]: realized he mixed up Robin and Aimee
* [14:54] [[User:Soft Linden|Soft Linden]]: Ah, because the artwork has to go into the tarball, gotcha
* [14:54] [[User:Aimee Trescothick|Aimee Trescothick]]: that's OK, I get myself mixed up all the time
* [14:54] [[User:Melinda Latynina|Melinda Latynina]]: artwork is far more easily changed/fixed later and therefore lower risk
* [14:55] [[User:Aimee Trescothick|Aimee Trescothick]]: yep, if I commit the patch before it's present, things will break/the universe will implode etc.
* [14:55] [[User:Soft Linden|Soft Linden]]: I think with a special case like that, you can just ask a Linden to commit the art for you when you'd be ready to commit code. Then go ahead and commit code when you see the export complete with the art in it.
* [14:55] [[User:Soft Linden|Soft Linden]]: Just get to the point where the group's signed off on the code, and you can kick off that request for help from a Linden.
* [14:56] [[User:Aimee Trescothick|Aimee Trescothick]]: ok
* [14:56] [[User:Squirrel Wood|Squirrel Wood]]: tosses code completion and auto indentation into the script editor improvement battle pit. Place your bet while you still can :p
* [14:56] [[User:Melinda Latynina|Melinda Latynina]]: Don't know if it's been mentioned but Rob created this plug-in task: https://jira.secondlife.com/browse/VWR-5560
* [14:57] [[User:Q Linden|Q Linden]]: Heh, that's an external version of the one I wrote ages ago
* [14:58] [[User:JB Kraft|JB Kraft]]: i vote elisp integration to the editor and then we are done! *ducks*
* [14:58] [[User:Q Linden|Q Linden]]: nudges conversation firmly bakc to plugins
* [14:58] [[User:Q Linden|Q Linden]]: I'll kick off the discussion on sldev with a reference to this JIRA. Thanks, Melinda!
* [14:58] [[User:Q Linden|Q Linden]]: any last comments? I've got a hard stop in 2 min
* [14:59] [[User:Melinda Latynina|Melinda Latynina]]: JB: IIRC Richard proposed an OS editor that itself had a plug-in archetecture. do u remember what that was?
* [14:59] [[User:JB Kraft|JB Kraft]]: i dont recall at the moment
* [14:59] [[User:Mm Alder|Mm Alder]]: I'd still like more documentation of the open source viewer process on the wiki
* [15:00] [[User:Soft Linden|Soft Linden]]: Mm - sometimes the best way to kick off documentation is to write the skeleton. People are often more motivated to fill in incomplete or wrong information than they are to start a fresh doc.
* [15:00] [[User:Morgaine Dinova|Morgaine Dinova]]: Great to see that there's a lot of internal interest in this general direction of plugins/external facilities . Our multicores are getting bored. :-)
* [15:00] [[User:Merov Linden|Merov Linden]]: Alder: I think Rob fully intends to fluff up what he wrote so far
* [15:00] [[User:Soft Linden|Soft Linden]]: That sums up the entirety of the wikipedia article lifecycle right there :)
* [15:01] [[User:Mm Alder|Mm Alder]]: I could make something up :-)
* [15:01] [[User:Q Linden|Q Linden]]: And with that, I've gotta run. Thanks all, I'll post to wiki.
* [15:01] [[User:Morgaine Dinova|Morgaine Dinova]]: Thanks Q
* [15:01] [[User:Aimee Trescothick|Aimee Trescothick]]: Thank Q :)
* [15:01] [[User:Mm Alder|Mm Alder]]: Thanks all
* [15:01] [[User:Soft Linden|Soft Linden]]: Posting what you think is right, then dropping a link on sldev is likely to kick off the right discussions & motivate contributions.

Open Source Meeting/2009-04-30

2009-04-30T23:38:44Z

Q Linden: New page: * [14:25] Q Linden: Simultaneously * [14:25] Morgaine Dinova: Is there a wiki page for Philip's viewer, something with links off to the relevan...

* [14:25] [[User:Q Linden|Q Linden]]: Simultaneously
* [14:25] [[User:Morgaine Dinova|Morgaine Dinova]]: Is there a wiki page for Philip's viewer, something with links off to the relevant data?
* [14:25] [[User:Soft Linden|Soft Linden]]: yus :>
* [14:25] [[User:Melinda Latynina|Melinda Latynina]]: this is all still very much a work-in-progress, no? I.E. can't have permanant rules & regulations yet, but the good news is that we all get to help drive the direction.
* [14:25] [[User:Morgaine Dinova|Morgaine Dinova]]: checks
* [14:26] [[User:Q Linden|Q Linden]]: Seriously, though, I think that we're moving toward "post a patch, post on SLDev for feedback, react to feedback, eventually check in patch."
* [14:26] [[User:Mm Alder|Mm Alder]]: But none of the policy seems to be written down yet.
* [14:26] [[User:Merov Linden|Merov Linden]]: when Philip was there remember , he didn't want to start the project with a long list of "processes" and "regulation"
* [14:27] [[User:Mm Alder|Mm Alder]]: I'm trying to get in literally a one bit change and I'm finding it very difficult.
* [14:27] [[User:Merov Linden|Merov Linden]]: so his idea was more: proposes something on list and we get from there
* [14:27] [[User:Q Linden|Q Linden]]: mm, you mean lip flap?
* [14:27] [[User:Merov Linden|Merov Linden]]: which one Alder?
* [14:27] [[User:Soft Linden|Soft Linden]]: I wouldn't anticipate that subsequent contributions have the overhead of the first dozen.
* [14:27] [[User:Mm Alder|Mm Alder]]: yes
* [14:28] [[User:Morgaine Dinova|Morgaine Dinova]]: Well in theory Philip's branch was intended to make it *easier* to commit changes. If it's still not easy enough, maybe a third LL VWR project is needed :P
* [14:28] [[User:Morgaine Dinova|Morgaine Dinova]]: laughs
* [14:28] [[User:Soft Linden|Soft Linden]]: :)
* [14:28] [[User:Q Linden|Q Linden]]: facepalms
* [14:28] [[User:Soft Linden|Soft Linden]]: Hold off on assuming that you know what the final process looks like until a few patches have gone through.
* [14:29] [[User:Merov Linden|Merov Linden]]: Your contribution has been voted "in" Alder
* [14:29] [[User:Mm Alder|Mm Alder]]: Does it have to be this hard?
* [14:29] [[User:Q Linden|Q Linden]]: we sure hope not
* [14:30] [[User:Q Linden|Q Linden]]: but we're still working it out...and everyone is still tentative
* [14:30] [[User:Robin Cornelius|Robin Cornelius]]: i was very suprised by the reaction to such a simple change
* [14:30] [[User:Soft Linden|Soft Linden]]: Anything touching on voice invites an awful lot of friction. I don't fully understand it myself.
* [14:30] [[User:Squirrel Wood|Squirrel Wood]]: At least we know that one contribution method still involves bottles of scotch brought directly to the San Francisco, Brighton, Boston and Chicago offices. ^^
* [14:30] [[User:Q Linden|Q Linden]]: maybe we're just used to the surprise
* [14:30] [[User:Melinda Latynina|Melinda Latynina]]: is not tentative :-)
* [14:31] [[User:Robin Cornelius|Robin Cornelius]]: i would have 2nd my self but i've never evern seen teh code running as i almost never use voice, so i don't feel i can approve any code i can't test my self
* [14:31] [[User:Squirrel Wood|Squirrel Wood]]: Or so I've heard.
* [14:31] [[User:Mm Alder|Mm Alder]]: So when I want to contribute my next patch which has popup menus and writes files, what then?
* [14:31] [[User:Merov Linden|Merov Linden]]: Alder: not everybody has commit privileges so it's assigned to someone who has
* [14:31] [[User:Morgaine Dinova|Morgaine Dinova]]: Might have been a good time to move to Hg actually.
* [14:31] [[User:Robin Cornelius|Robin Cornelius]]: MM if its an area i know, then i would be happy to look
* [14:31] [[User:Merov Linden|Merov Linden]]: this someone is me now
* [14:31] [[User:Aimee Trescothick|Aimee Trescothick]]: well Hg is there now at least :)
* [14:31] [[User:Soft Linden|Soft Linden]]: Hg is coming. And we did talk about using it for this, but didn't want yet another thing that had to be working before launching.
* [14:32] [[User:Merov Linden|Merov Linden]]: so you can kick my butt now if that doesn't move forward
* [14:32] [[User:Q Linden|Q Linden]]: morgaine, we're almost all the way to hg
* [14:32] [[User:Morgaine Dinova|Morgaine Dinova]]: Woohoo!
* [14:32] [[User:Q Linden|Q Linden]]: can't happen fast enough for me. :)
* [14:32] [[User:Mm Alder|Mm Alder]]: Hg?
* [14:32] [[User:Q Linden|Q Linden]]: Mercurial source control
* [14:32] [[User:Aimee Trescothick|Aimee Trescothick]]: [http://bitbucket.org/lindenlab/http-texture/]
* [14:33] [[User:Q Linden|Q Linden]]: OK? "I wonder if someone could give a brief update on the status of plugin explorations." -- JB Kraft
* [14:33] [[User:JB Kraft|JB Kraft]]: i found some discussion on the dev list from a couple of years ago, soft did some work on this i belive. just wondered if it stalled and why and what spark might ignite it again, if any?
* [14:33] [[User:Robin Cornelius|Robin Cornelius]]: people have been contacting me recently about this as well
* [14:33] [[User:Q Linden|Q Linden]]: JB, it's smouldering as we speak
* [14:34] [[User:Morgaine Dinova|Morgaine Dinova]]: Mm: [http://www.selenic.com/mercurial/wiki/] , [http://en.wikipedia.org/wiki/Mercurial_(software)]
* [14:34] [[User:Soft Linden|Soft Linden]]: I sooooo want plugins. :<
* [14:34] [[User:Merov Linden|Merov Linden]]: me too
* [14:34] [[User:Soft Linden|Soft Linden]]: oops gesture
* [14:34] [[User:JB Kraft|JB Kraft]]: yeah, it would be nice :) is there anything form outside that might push it along?
* [14:34] [[User:Q Linden|Q Linden]]: the stall has been that this is one case where the hack is the true enemy of a good design, because we'll be stuck with it forever (*cough*skin layers*cough*)
* [14:35] [[User:Merov Linden|Merov Linden]]: it's not easy to get it right from the host standpoint
* [14:35] [[User:Morgaine Dinova|Morgaine Dinova]]: Plugins in what? In viewer? If anyone's working on that, I'd love to talk to them, since that's my goal for Imprudence.
* [14:35] [[User:Q Linden|Q Linden]]: so we've been working on an event system that would act as the transport of information between plugins
* [14:35] [[User:JB Kraft|JB Kraft]]: ah ok, that is good news
* [14:35] [[User:Q Linden|Q Linden]]: You can see a preview of some of these ideas in the Notifications event API, but that's not complete yet
* [14:36] [[User:Merov Linden|Merov Linden]]: Q: using IPC?
* [14:36] [[User:Melinda Latynina|Melinda Latynina]]: JB: weren't you looking into a plug-in archetecture for text editors?
* [14:36] [[User:Q Linden|Q Linden]]: boost signals
* [14:36] [[User:JB Kraft|JB Kraft]]: yes, the editor is one of my pet projects and that was a part of it. thats why i wondered :)
* [14:37] [[User:Q Linden|Q Linden]]: and...not coincidentally, we actually wanted to talk about script editor improvements today
* [14:37] [[User:Q Linden|Q Linden]]: we thought it would be a good time to start the design discussion on sldev/here
* [14:38] [[User:Melinda Latynina|Melinda Latynina]]: i believe we can have plug-ins in multiple places and deal with the merits and weaknesses of each rather than try to find a one-size-fits-all
* [14:38] [[User:Q Linden|Q Linden]]: projects like [http://web.mit.edu/~eric_r/Public/S4SL/] (scratch for second life) need a plugin editor
* [14:38] [[User:JB Kraft|JB Kraft]]: excellent! i have a bunch of patches for the editor but kind of got discouraged with process tbh. it would be great to hack out a path for it :)
* [14:39] [[User:Morgaine Dinova|Morgaine Dinova]]: [http://imprudenceviewer.org/w/images/4/48/Plugin_system_flow_APIs.png] --- that gives a general view of our plugin architecture for Imprudence.
* [14:40] [[User:Squirrel Wood|Squirrel Wood]]: improvements... one simple improvements would be to allow bulk uploads of .txt and .lsl files ?
* [14:40] [[User:Q Linden|Q Linden]]: yes, morgaine...but some of the details of how the sockets communicate and what the control model is are key to getting this right
* [14:40] [[User:Q Linden|Q Linden]]: so I like that chart, but I want more. :)
* [14:40] [[User:Morgaine Dinova|Morgaine Dinova]]: This is the general forum, everything marked as [Plugins
* [14:40] [[User:Morgaine Dinova|Morgaine Dinova]]: [http://imprudenceviewer.org/forums/viewforum.php?f=7&sid=d27038a45f73559be80b8cda33c3cc5b]
* [14:41] [[User:JB Kraft|JB Kraft]]: squirrel, i have a patch on the jira that load and saves from the editor to disc, kudgly at the mo but it works for me
* [14:41] [[User:Morgaine Dinova|Morgaine Dinova]]: Q: yep, the internal viewer API is central, and clearly needs to be event-based.
* [14:41] [[User:Robin Cornelius|Robin Cornelius]]: JB i think squirrel whats the File->Uload->Bulk to support text for notecards and scripts (with approprate expension)
* [14:42] [[User:JB Kraft|JB Kraft]]: ah, right
* [14:42] [[User:Robin Cornelius|Robin Cornelius]]: pretty simple to do actually
* [14:42] [[User:Squirrel Wood|Squirrel Wood]]: there is a jira somewhere for it even ^^
* [14:42] [[User:Robin Cornelius|Robin Cornelius]]: but loading and saving from the text editor is a godsend
* [14:43] [[User:Morgaine Dinova|Morgaine Dinova]]: Q: are you thinking as we are then, that decoupling plugins from the viewer monolith is the key to sanity?
* [14:43] [[User:Q Linden|Q Linden]]: yes
* [14:43] [[User:Q Linden|Q Linden]]: *I* am
* [14:43] [[User:Morgaine Dinova|Morgaine Dinova]]: Great to hear! :-)
* [14:43] [[User:JB Kraft|JB Kraft]]: https://jira.secondlife.com/browse/VWR-5206
* [14:43] [[User:Q Linden|Q Linden]]: And we're moving in that direction...but honestly, it's a multi-year effort
* [14:43] [[User:Morgaine Dinova|Morgaine Dinova]]: Yep. not easy
* [14:43] [[User:Q Linden|Q Linden]]: A big chunk of our work this year is going to enabling that decoupling
* [14:43] [[User:JB Kraft|JB Kraft]]: thats awesome Q!
* [14:44] [[User:Mm Alder|Mm Alder]]: Please don't forget, "Is there anyone other than me who would be interested in open code reviews for this project? Mm Alder 15:57, 30 April 2009 (UTC) "
* [14:44] [[User:Morgaine Dinova|Morgaine Dinova]]: Just binding in a language would be pretty trivial, bit the wrong thing to do, if there is to be any hope of stability and portability.
* [14:44] [[User:Q Linden|Q Linden]]: right, morgaine; whatever we do, we do forever
* [14:45] [[User:Q Linden|Q Linden]]: so we really want to make sure it has a future
* [14:45] [[User:Q Linden|Q Linden]]: (while not living in analysis paralysis forever either!)
* [14:45] [[User:Morgaine Dinova|Morgaine Dinova]]: Yeah
* [14:45] [[User:Robin Cornelius|Robin Cornelius]]: mm, i'm fully up for open code reviews
* [14:45] [[User:Aimee Trescothick|Aimee Trescothick]]: yes
* [14:46] [[User:Squirrel Wood|Squirrel Wood]]: JB: https://jira.secondlife.com/browse/VWR-7959
* [14:46] [[User:Q Linden|Q Linden]]: mm, that's what I thought the idea was behind posting the patch on jira before applying it
* [14:46] [[User:Q Linden|Q Linden]]: is that not the same thing you're saying?
* [14:46] [[User:Morgaine Dinova|Morgaine Dinova]]: Q: if anything happens on Imprudence plugins (and that's not certain), I'd appreciate your feedback.
* [14:46] [[User:Mm Alder|Mm Alder]]: No, I mean a code presentation in-world where people can ask questions and learn a bit about what the code does.
* [14:47] [[User:Robin Cornelius|Robin Cornelius]]: sounds like what Phillip was taking about
* [14:47] [[User:Merov Linden|Merov Linden]]: Alder: that's more of a "design review" then (as in "code design")
* [14:47] [[User:Mm Alder|Mm Alder]]: Philip was talking about it, but then ....
* [14:47] [[User:Q Linden|Q Linden]]: The more of that we see, the better....but I'm not sure it needs to be a required part of every submission.
* [14:48] [[User:Q Linden|Q Linden]]: depends a lot on the scope of what's happening, I guess
* [14:48] [[User:Q Linden|Q Linden]]: I think a valid response to "hey, I've just attached a patch" would be "I'd like to have a conversation about this inworld."
* [14:48] [[User:Mm Alder|Mm Alder]]: If I were to ask someone to review my patch for editing morphs, I would be surprised if anyone would understand it without explanation.
* [14:48] [[User:Merov Linden|Merov Linden]]: Alder: are you talking about general part of the viewer architecture or specific submission?
* [14:49] [[User:Mm Alder|Mm Alder]]: Specific submission. But you'd also learn about the viewer in the process just by listening.
* [14:49] [[User:Merov Linden|Merov Linden]]: understood
* [14:49] [[User:Morgaine Dinova|Morgaine Dinova]]: Instead of conversations in-world, how about insisting on Doxygen-style documentation in patches instead? That can be anything, including design documentation.
* [14:49] [[User:Mm Alder|Mm Alder]]: I can ask Doxygen a question. :-)
* [14:50] [[User:JB Kraft|JB Kraft]]: +1 morgaine
* [14:51] [[User:Merov Linden|Merov Linden]]: well, on one instance, (VWR-12748 submitted by Robin) I reviewed and proposed a modified patch, she modified, etc...
* [14:51] [[User:Mm Alder|Mm Alder]]: I love Doxygen, but it can't replace a human who understands the code.
* [14:51] [[User:Merov Linden|Merov Linden]]: so the code review was done in the JIRA through a back and forth of commented patches
* [14:51] [[User:Morgaine Dinova|Morgaine Dinova]]: Mm: hehe, well Doxygen only reflects what devs put it ... but if there's a long chuck of code without any human-added Doxygen headers, then I think it's reasonable to ask "Hey, how about some explanatory text for this?" :-)
* [14:52] [[User:Q Linden|Q Linden]]: me too
* [14:52] [[User:Merov Linden|Merov Linden]]: I guess IW presentation would be good for general part of the architecture or really hairy patches
* [14:52] [[User:Q Linden|Q Linden]]: that's a part of a good code review -- it shouldn't be just "does it work" but "is it maintainable"
* [14:53] [[User:Melinda Latynina|Melinda Latynina]]: likes the idea of IW code/design reviews
* [14:54] [[User:Q Linden|Q Linden]]: So Aimee asks "Procedure for getting supporting artwork in before committing a patch to http-texture? i.e. VWR-12748[c
* [14:54] [[User:Merov Linden|Merov Linden]]: realized he mixed up Robin and Aimee
* [14:54] [[User:Soft Linden|Soft Linden]]: Ah, because the artwork has to go into the tarball, gotcha
* [14:54] [[User:Aimee Trescothick|Aimee Trescothick]]: that's OK, I get myself mixed up all the time
* [14:54] [[User:Melinda Latynina|Melinda Latynina]]: artwork is far more easily changed/fixed later and therefore lower risk
* [14:55] [[User:Aimee Trescothick|Aimee Trescothick]]: yep, if I commit the patch before it's present, things will break/the universe will implode etc.
* [14:55] [[User:Soft Linden|Soft Linden]]: I think with a special case like that, you can just ask a Linden to commit the art for you when you'd be ready to commit code. Then go ahead and commit code when you see the export complete with the art in it.
* [14:55] [[User:Soft Linden|Soft Linden]]: Just get to the point where the group's signed off on the code, and you can kick off that request for help from a Linden.
* [14:56] [[User:Aimee Trescothick|Aimee Trescothick]]: ok
* [14:56] [[User:Squirrel Wood|Squirrel Wood]]: tosses code completion and auto indentation into the script editor improvement battle pit. Place your bet while you still can :p
* [14:56] [[User:Melinda Latynina|Melinda Latynina]]: Don't know if it's been mentioned but Rob created this plug-in task: https://jira.secondlife.com/browse/VWR-5560
* [14:57] [[User:Q Linden|Q Linden]]: Heh, that's an external version of the one I wrote ages ago
* [14:58] [[User:JB Kraft|JB Kraft]]: i vote elisp integration to the editor and then we are done! *ducks*
* [14:58] [[User:Q Linden|Q Linden]]: nudges conversation firmly bakc to plugins
* [14:58] [[User:Q Linden|Q Linden]]: I'll kick off the discussion on sldev with a reference to this JIRA. Thanks, Melinda!
* [14:58] [[User:Q Linden|Q Linden]]: any last comments? I've got a hard stop in 2 min
* [14:59] [[User:Melinda Latynina|Melinda Latynina]]: JB: IIRC Richard proposed an OS editor that itself had a plug-in archetecture. do u remember what that was?
* [14:59] [[User:JB Kraft|JB Kraft]]: i dont recall at the moment
* [14:59] [[User:Mm Alder|Mm Alder]]: I'd still like more documentation of the open source viewer process on the wiki
* [15:00] [[User:Soft Linden|Soft Linden]]: Mm - sometimes the best way to kick off documentation is to write the skeleton. People are often more motivated to fill in incomplete or wrong information than they are to start a fresh doc.
* [15:00] [[User:Morgaine Dinova|Morgaine Dinova]]: Great to see that there's a lot of internal interest in this general direction of plugins/external facilities . Our multicores are getting bored. :-)
* [15:00] [[User:Merov Linden|Merov Linden]]: Alder: I think Rob fully intends to fluff up what he wrote so far
* [15:00] [[User:Soft Linden|Soft Linden]]: That sums up the entirety of the wikipedia article lifecycle right there :)
* [15:01] [[User:Mm Alder|Mm Alder]]: I could make something up :-)
* [15:01] [[User:Q Linden|Q Linden]]: And with that, I've gotta run. Thanks all, I'll post to wiki.
* [15:01] [[User:Morgaine Dinova|Morgaine Dinova]]: Thanks Q
* [15:01] [[User:Aimee Trescothick|Aimee Trescothick]]: Thank Q :)
* [15:01] [[User:Mm Alder|Mm Alder]]: Thanks all
* [15:01] [[User:Soft Linden|Soft Linden]]: Posting what you think is right, then dropping a link on sldev is likely to kick off the right discussions & motivate contributions.

Open Source Meeting

2009-04-30T23:37:57Z

Q Linden:

[[Image:Opensource meetings at Hippotropolis.jpg|right]]

Open source meeting - Thursday, 2pm PT in [http://slurl.com/secondlife/Hippotropolis/239/28/24/?img=https%3A//wiki.secondlife.com/w/images/9/91/Opensource_meetings_at_Hippotropolis.jpg Hippotropolis]

Transcripts are posted after every meeting (see below) so don't put anything into chat that you don't want to see posted here.

[[Open Source Meeting/Agenda]]

<br\>
Rob Linden has been posting below the transcripts of the meetings, but if they're not there, here's how to do that:

* Press the blue History button (renamed "Local Chat" in 1.19 viewer) to see all the chat that scrolled off the screen, then cut-n-paste that into any text editor. Also, in Preferences, on the Communication tab, you can set up a log file to your local disk.
* Use the Wikifier at http://www.treekyomoon.com/wikifier.htm to format the text.
* Add a link below (You have to be logged in to edit.)
* Select the link to bring you into edit mode for the new page, and paste the Wikified transcript.
<br\>

; Past Meetings
<ul style="-moz-column-count:3; -webkit-column-count:3; column-count:3;">
*[[Open Source Meeting/2009-04-30]]
*[[Open Source Meeting/2009-04-07]]
*[[Open Source Meeting/2009-04-02]]
*[[Open Source Meeting/2009-03-26]]
*[[Open Source Meeting/2009-03-19]]
*[[Open Source Meeting/2009-03-12]]
*[[Open Source Meeting/2009-03-05]]
*[[Open Source Meeting/2009-02-26]]
*[[Open Source Meeting/2009-02-19]]
*[[Open Source Meeting/2009-02-12]]
*[[Open Source Meeting/2009-02-05]]
*[[Open Source Meeting/2009-01-29]]
*[[Open Source Meeting/2009-01-22]]
*[[Open Source Meeting/2009-01-15]]
*[[Open Source Meeting/2009-01-08]]
*[[Open Source Meeting/2008-12-18]]
*[[Open Source Meeting/2008-12-04]]
*[[Open Source Meeting/2008-11-20]]
*[[Open Source Meeting/2008-11-13]]
*[[Open Source Meeting/2008-11-06]]
*[[Open Source Meeting/2008-10-30]]
*[[Open Source Meeting/2008-10-23]]
*[[Open Source Meeting/2008-10-16]]
*[[Open Source Meeting/2008-10-09]]
*[[Open Source Meeting/2008-10-02]]
*[[Open Source Meeting/2008-09-25]]
*[[Open Source Meeting/2008-09-18]]
*[[Open Source Meeting/2008-09-11]]
*[[Open Source Meeting/2008-09-04]]
*[[Open Source Meeting/2008-08-28]]
*[[Open Source Meeting/2008-08-21]]
*[[Open Source Meeting/2008-08-14]]
*[[Open Source Meeting/2008-08-07]]
*[[Open Source Meeting/2008-07-31]]
*[[Open Source Meeting/2008-07-24]]
*[[Open Source Meeting/2008-07-17]]
*[[Open Source Meeting/2008-07-10]]
*[[Open Source Meeting/2008-07-03]]
*[[Open Source Meeting/2008-06-26]]
*[[Open Source Meeting/2008-06-19]]
*[[Open Source Meeting/2008-06-12]]
*[[Open Source Meeting/2008-06-05]]
*[[Open Source Meeting/2008-05-29]]
*[[Open Source Meeting/2008-05-22]]
*[[Open Source Meeting/2008-05-15]]
*[[Open Source Meeting/2008-05-08]]
*[[Open Source Meeting/2008-04-10]]
*[[Open Source Meeting/2008-04-03]]
*[[Open Source Meeting/2008-03-27]]
*[[Open Source Meeting/2008-03-20]]
*[[Open Source Meeting/2008-03-13]]
*[[Open Source Meeting/2008-03-06]]
*[[Open Source Meeting/2008-02-14]]
*[[Open Source Meeting/2008-02-07]]
*[[Open Source Meeting/2008-01-17]]
*[[Open Source Meeting/2008-01-03]]
*[[Open Source Meeting/2007-12-20]]
*[[Open Source Meeting/2007-12-13]]
*[[Open Source Meeting/2007-12-06]]
*[[Open Source Meeting/2007-11-29]]
*[[Open Source Meeting/2007-11-22]]
*[[Open Source Meeting/2007-11-15]]
*[[Open Source Meeting/2007-11-08]]
*[[Open Source Meeting/2007-11-01]]
*[[Open Source Meeting/2007-10-25]]
*[[Open Source Meeting/2007-10-18]]
*[[Open Source Meeting/2007-10-11]]
*[[Open Source Meeting/2007-10-04]]
*[[Open Source Meeting/2007-09-27]]
*[[Open Source Meeting/2007-09-20]]
*[[Open Source Meeting/2007-09-06]]
*[[Open Source Meeting/2007-08-30]]
*[[Open Source Meeting/2007-08-23]]
*[[Open Source Meeting/2007-08-16]]
*[[Open Source Meeting/2007-07-19]]
*[[Open Source Meeting/2007-07-12]]
</ul>

[[Category:Open Source Portal]]
[[Category:Office Hours| ]]

Open Source Meeting/Agenda

2009-04-30T15:35:11Z

Q Linden: /* Agenda */

< [[Open Source Meeting]]

Open source meeting - Thursday, 2pm PT.

[http://slurl.com/secondlife/Hippotropolis/248/15/25/ Teleport] to the Linden Open Source Project headquarters.

Please try to add your items as early as possible in the week to give Rob a chance to round up any Lindens that may be appropriate to the discussion. Please also bring large or contentious items up on [[SLDev]] before or concurrently with adding them as agenda items.

== Agenda ==

30Apr2009 -- Meeting will be moderated by Q Linden

* 1.23 RC0 -- comments? questions?
* Other items?

Default agenda (barring agenda above):
* Update from the Lindens (standing item) - [[User:Rob Linden|Rob Linden]]
* Triage of issues listed here: http://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=11240

[[Category:Open Source Meeting]]

Open Source Meeting/Agenda

2009-04-30T15:33:52Z

Q Linden: /* Agenda */

< [[Open Source Meeting]]

Open source meeting - Thursday, 2pm PT.

[http://slurl.com/secondlife/Hippotropolis/248/15/25/ Teleport] to the Linden Open Source Project headquarters.

Please try to add your items as early as possible in the week to give Rob a chance to round up any Lindens that may be appropriate to the discussion. Please also bring large or contentious items up on [[SLDev]] before or concurrently with adding them as agenda items.

== Agenda ==

Meeting will be moderated by Q Linden today
* 1.23 RC0 -- comments? questions?
* Other items?

Default agenda (barring agenda above):
* Update from the Lindens (standing item) - [[User:Rob Linden|Rob Linden]]
* Triage of issues listed here: http://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=11240

[[Category:Open Source Meeting]]

User:Q Linden/Office Hours

2008-07-28T16:06:19Z

Q Linden:

{{Office Hours |Resident=Q Linden |http://slurl.com/secondlife/Longfellow/200/136/34?title=Q%27s%20Land%20in%20Linden%20Village |times=* Wednesdays, 8:00-9:00 AM PDT |topics=* User experience, construction, architecture, open source, science fiction, cycling, games|location=[http://slurl.com/secondlife/Longfellow/220/168/25 Q's land] |}}

User:Q Linden/Office Hours

2008-07-28T13:29:42Z

Q Linden:

{{Office Hours |Resident=Q Linden |http://slurl.com/secondlife/Longfellow/200/136/34?title=Q%27s%20Land%20in%20Linden%20Village |times=* Mondays, 7:30-8:30 AM PDT (NOTE: will be changing as of August 2008!) |topics=* User experience, construction, architecture, open source, science fiction, cycling, games|location=[http://slurl.com/secondlife/Longfellow/220/168/25 Q's land] |}}

Talk:VFS

2008-06-19T20:29:24Z

Q Linden: /* VFS index: std::map (low hanging fruit) */

{{Open Source Talk Page}}

Related discussions:
* [http://forums.secondlife.com/showthread.php?t=159552 OpenClient: Cache operation discussion]
* [[Talk:Texture cache]]

==Alternative implementation==
Only desk-checked:
<pre>

// N_LEVELS * N_CHARS should probably not be greater than 8, since there's a
// separator in the UUID there.
#define N_LEVELS 2
// UUID is hex, so 2 chars means maximum of 256 directories per level
#define N_CHARS 2

#ifdef I_KNOW_THIS_ITS_A_UNIX_SYSTEM
# define DIR_SEP '/'
#else
# define DIR_SEP '\\'
#endif

extern char *cache_dir;
extern int safe_make_directory_path(char *path);

FILE *fopen_texture(char *filename, char *mode)
{
int l = strlen(cache_dir);
int m = strlen(filename);
char *new_filename = calloc(l + 1 + m + N_LEVELS * (N_CHARS + 1) + 1);
char *s, *t;
int i, j;
FILE *fp;

if (!new_filename) return NULL;

s = filename;
t = new_filename;
strcpy(t, cache_dir);
t += l;

for (i = 0; *s && i < N_LEVELS; i++)
{
*t++ = DIR_SEP;
for (j = 0; *s && j < N_CHARS; j++)
*t++ = *s++;
}
*t = '\0';
if (!safe_make_directory_path(new_filename)) return free(new_filename), NULL;
*t++ = DIR_SEP;

strcpy(t, filename);

fp = fopen(new_filename, mode);
free(new_filename);
return fp;
}
</pre>

== VFS index: std::map (low hanging fruit) ==

I've been reading through the STL source and documentation. std::map by itself is the wrong solution for the index. [[User:Strife Onizuka|Strife Onizuka]] 11:29, 27 March 2007 (PDT)
#It is only sorted explicitly (std::sort)
#map.find has a n-based time frame.
#*A cache with 20,000 assets has to do 20,000 comparisons when it wants to find out about the most recently added asset.

Solutions:
<ul><ol start="" style="list-style-type:upper-alpha">
<li>
'''Sort the map:'''
#Keep the map sorted by doing a binary search to determine where an asset should be inserted.
#*A cache with 20,000 assets would only have to do about 16 comparisons to add an asset
#Use std::lower_bound instead of map.find (map.lower_bound suffers from the same problem as map.find)
'''Problems:'''
*The bulk of the index needs to be written to disk when a single asset is added. mIndexHoles & LLVFS::sync can't be used when adding assets.
<li>
'''Keep a duplicated sorted map (without the holes):'''
#All requests into the cache would go through the new map, the old map is used to handle positions and allow for the use of mIndexHoles.
'''Problems:'''
*Extra resources required for maintaining two maps.
</ol></ul>

I'm not sure where the confusion was, but this is just not true.
Map implements a binary tree on the key, based on operator< comparisons of the keys.
It's stored in sorted order, and the find algorithm has O(log(N)) complexity.
The free blocks list is also a map (a multimap) stored by length.
This is just not "low-hanging fruit".
-- [[User:Q Linden|Q Linden]] 13:29, 19 June 2008 (PDT)

== Fragmentation ==

The free space in the VFS can become fragmented, I estimate about 4% would be the upper limit on the amount of unusable free space due to fragmentation. There are many small assets, and the current alg tries to fit assets into appropriately sized spaces. About 6% of assets are one block in size. Defragmenting the cache doesn't seem practical. [[User:Strife Onizuka|Strife Onizuka]] 11:55, 27 March 2007 (PDT)

== Creating new files in a full VFS - Remarks ==

It seems, that to create a new file in a full VFS, the VFS deletes all LRU files until a big enough chunk "appears" to write the file to. This deletes an unnecessary big number of files. Wouldn't it be better to:

- Use the old algorithm to find a big enough chunk.

- Only delete the files that are located in that chunk.

One remaining question is, whether to write the new file at the beginning or the end of the chunk (assuming that the chunk is larger than the file). As an optimization, one could make this decision based on which file (the one in front of the new one or the one behind) is more recently used. Putting it closer to the more recently used neighbor makes it more likely to later free a larger chunk: The less recently used neighbor is more likely to be deleted first and when deleted, will have the remaining free space from our initial chunk adjacent to it. Those two free chunks can then be merged. -- {{unsigned|Dreamer Miquel}} 10:58, 31 August 2007 (PDT)

Message

2008-02-18T14:49:59Z

Q Linden: /* update quaternion info */

{{OSWikiLearnBox|parent=Protocol}}

=Definition=

A message is the basic communications unit for the Second Life world. Messages are used to pass serialized information about almost every part of the system back and forth between two hosts on a network, through connections known as [[circuits]].

There are many hundreds of messages in the Second Life message system. A list of them is available at [[:Category:Messages]].

=Message Format=

Messages are defined in the [[Message Template]]. They follow the format:

<pre>
{
[Message Name] [Message Frequency] [Message Trust Level] [Message Encoding]
{
[Block 1 Name] [Block 1 Quantity]
{ [Block 1 Parameter 1 Name] [Block 1 Parameter 1 Type] }
{ [Block 2 Parameter 2 Name] [Block 2 Parameter 2 Type] }
[...]
}
[...]
{
[Block n Name] [Block n Quantity]
{ [Block n Parameter 1 Name] [Block n Parameter 1 Type] }
[...]
}
}
</pre>

For example

<pre width=80>
{
TestMessage Low 1 NotTrusted Zerocoded
{
TestBlock1 Single
{ Test1 U32 }
}
{
NeighborBlock Multiple 4
{ Test0 U32 }
{ Test1 U32 }
{ Test2 U32 }
}
}
</pre>

==Preamble==

The preamble contains information about the message as a whole.

*Name
**Values: [string]
**Name of the message. Follows C variable naming restrictions.
*Frequency
**Values: High|Medium|Low|Fixed [U32]
**Determines whether the message ID is 8, 16, or 32 bits. There can be 254 messages in the High or Medium, 32K in Low. A message with a "Fixed" frequency defines its own ID and is considered to be a signal. For more information, see [[Packet Layout]]
*Trust Level
**Values: Trusted|NotTrusted
**Denotes the minimum trust level needed for the [[circuit]] between the sender and receiver in order for the message to send successfully. For more information, see [[Circuits]].
*Compression
**Values: Unencoded|Zerocoded
**Zerocoding will attempt to compress sequences of zeros in the message in order to reduce network load. If there is no major size difference after the compression, it is discarded and the message is sent uncompressed.

==Blocks==

Blocks are delimiters for groups of data in a message.

*Name
**Values: [string]
**Name of the block. Follows C variable naming restrictions.
*Quantity
**Values: Single|Multiple [U8]|Variable
**Determines how many blocks are contained in the message. "Multiple" means a static number of blocks in every message, and is followed by an 8 bit number to tell how many times the block is repeated, "Variable" lets the sender specify the number of blocks on sending (also an 8 bit number).

==Variables==

Variables contain the data sent with the message

*Name
**Values: [string]
**Name of the variable. Follows C variable naming restrictions.
* Type
**Values: Null|Fixed [U32]|Variable [U32]|U8|U16|U32|U64|S8|S16|S32|S64|F32|F64
**Values Cont: LLVector3|LLVector3d|LLVector4|LLQuaternion|LLUUID|BOOL|IPADDR|IPPORT|U16Vec3|U16Quat|S16Array
**The type of the variable. "Fixed"/"Variable" are used to denote sizes for things like blobs.

==Data Types==

*Null - no data, 0 bytes wide
*Fixed - byte array, interpreted depending on packet type, width determined in message definition
*Variable - first byte determines number of bytes that follow
*U8 - unsigned byte, 1 byte wide
*U16 - unsigned short, 2 bytes wide
*U32 - unsigned int, 4 bytes wide
*U64 - unsigned long, 8 bytes wide
*S8 - signed byte, 1 byte wide
*S16 - signed short, 2 bytes wide
*S32 - signed int, 4 bytes wide
*S64 - signed long, 8 bytes wide
*F32 - float, 4 bytes wide
*F64 - double, 8 bytes wide
*LLVector3 - triplet of floats, 12 bytes wide
*LLVector3d - triplet of doubles, 24 bytes wide
*LLVector4 - quad of floats, 16 bytes wide
*LLQuaternion - because it's always a unit quaternion, transmitted in messages as a triplet of floats, 12 bytes wide (represented in memory as a quad of floats, 16 bytes wide)
*LLUUID - [[UUID|Universal ID]], 16 bytes wide
*BOOL - 0 or 1, 1 byte wide
*IPADDR - IP Address, one place per byte, 4 bytes wide
*IPPORT - IP Port, one byte wide
*U16Vec3 - not used
*U16Quat - not used
*S16Array - not used

User:Q Linden/Office Hours/2008-01-07

2008-01-08T14:39:22Z

Q Linden:

User:Q Linden/Office Hours/2008-01-07

2008-01-08T14:37:26Z

Q Linden: New page: <table border="0"> <tr bgcolor="yellow"><td width="7%">Time</td><td width="15%">Speaker</td><td>Remarks</td></tr> <tr><td bgcolor="#d0d0ff">[7:37]</td><td bgcolor="#d0ffd0">Ricken Flow</td...

User:Q Linden/Office Hours/2007-10-15

2007-10-18T17:58:09Z

Q Linden: Office hours from 10/15

<table border="0">
<tr bgcolor="yellow"><td width="7%">Time</td><td width="15%">Speaker</td><td>Remarks</td></tr>
<tr><td bgcolor="#d0d0ff">[7:35]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> Hello</td></tr>
<tr><td bgcolor="#d0d0ff">[7:35]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> hey</td></tr>
<tr><td bgcolor="#d0d0ff">[7:36]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> How are you ?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:36]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> fine. Nice avi.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:36]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> thanks</td></tr>
<tr><td bgcolor="#d0d0ff">[7:36]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I couldn't even find you for a sec!</td></tr>
<tr><td bgcolor="#d0d0ff">[7:36]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> I (ve many avies</td></tr>
<tr><td bgcolor="#d0d0ff">[7:36]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> I've*</td></tr>
<tr><td bgcolor="#d0d0ff">[7:36]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Anything in particular on your mind today?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:37]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> no :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:37]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> but that's the way I like to play</td></tr>
<tr><td bgcolor="#d0d0ff">[7:37]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I'm about to change the board...my intention is to post this conversation unless someone specificallly requests otherwise</td></tr>
<tr><td bgcolor="#d0d0ff">[7:37]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> ok</td></tr>
<tr><td bgcolor="#d0d0ff">[7:38]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> So what is your job in LL ?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:38]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I'm a developer</td></tr>
<tr><td bgcolor="#d0d0ff">[7:39]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I'm just moving over to a new group focusing on the client side of SL</td></tr>
<tr><td bgcolor="#d0d0ff">[7:39]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> Studio Shiny ?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:39]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> In particular, rearchitecting it so that it's more easily extended/reused.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:39]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> yes, shiny</td></tr>
<tr><td bgcolor="#d0d0ff">[7:39]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I'm hoping to make it a better platform for open source development</td></tr>
<tr><td bgcolor="#d0d0ff">[7:40]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> I'm surprise because open-source does'nt have is own studio</td></tr>
<tr><td bgcolor="#d0d0ff">[7:40]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> (and sorry for the mistakes, I'm french)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:40]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yeah...there are a few of us spread around the org who are trying to promote open source</td></tr>
<tr><td bgcolor="#d0d0ff">[7:41]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> ah, bon! I lived in france for a year...but we should probably talk in English because my French really isn't that good.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:41]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:41]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> where in france ?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Vence (northwest of Nice)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> nice</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> yes, it was really wonderful</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> I also live in the south of france</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> where?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> Lyon</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I've been there once.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> betwwen Nice and Paris</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> between*</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I went to a carnival there.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:43]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Do you ski?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:43]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> sometimes</td></tr>
<tr><td bgcolor="#d0d0ff">[7:43]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> the Alpes are not far away</td></tr>
<tr><td bgcolor="#d0d0ff">[7:43]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Pretty close to Briancon, right?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:43]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor="#d0ffd0">doesn't know how to type cedille</td></tr>
<tr><td bgcolor="#d0d0ff">[7:43]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> it takes 1h30 in car to go skiing</td></tr>
<tr><td bgcolor="#d0d0ff">[7:44]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> Briancon is in the south</td></tr>
<tr><td bgcolor="#d0d0ff">[7:44]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Ah, ok.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:44]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> What sorts of things do you like to do in SL?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> building</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> scripting</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> have fun with my frien Biouby</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> friend*</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> and collect Linden Bears</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor="#d0ffd0">accepted your inventory offer.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> Thank you !</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> You(re worjing in SL right now ?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> you're working*</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> What would you change about our building system?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:47]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I am working on viewer architecture changes, yes</td></tr>
<tr><td bgcolor="#d0d0ff">[7:47]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> first we want to get the viewer in shape to make bigger changes</td></tr>
<tr><td bgcolor="#d0d0ff">[7:47]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> building tools are easy to use</td></tr>
<tr><td bgcolor="#d0d0ff">[7:47]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> but we need larger prims than 10m</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> I know that Havok4 will change that, I hope</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Did you see the discussion on the SL blog today?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Or maybe yesterday</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> About megaprims?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> yes</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> What would you use bigger prims for?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> we'll save prims with them</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> for the buildings</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> ot houses</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> or*</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> (By the way, I agree with you -- I'd like to see larger prim limits, but maybe not in all 3 dimensions at once.)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> I don't ask 256x256m</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> but 50x50 would be great</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> would you mind if it was 50x50x1?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> if I can change, yes</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> for example, 50x20x1</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> right...just talking about maximum size</td></tr>
<tr><td bgcolor="#d0d0ff">[7:52]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> no promises, by the way! I won't be the one making this decision.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:52]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> I know</td></tr>
<tr><td bgcolor="#d0d0ff">[7:52]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> But I'll pass along opinions</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Have you used sculpties yet?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> no, I really think that the tools are ok</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> sculpties, I did an heart</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> but I'mvery bad</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> I tried on Maya</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> oh, with a maya sculptie converter?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> yes, the one Second Life gives</td></tr>
<tr><td bgcolor="#d0d0ff">[7:55]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> But I don't have enough skills to do big things</td></tr>
<tr><td bgcolor="#d0d0ff">[7:55]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Anyway, sculpties are one of the things I'd like to make easier</td></tr>
<tr><td bgcolor="#d0d0ff">[7:56]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I think we could have a sculptie system that lets people manipulate them in-world.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:56]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Which could save a lot of prims.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:56]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> but it's harder than prims</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yes....but it doesn't have to be as hard as it is now!</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> ok</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> Torley talked about particles system</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> for scripting</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I don't understand?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> now, the particle system in lsl is very hard</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Ah, I haven't tried to script particles</td></tr>
<tr><td bgcolor="#d0d0ff">[7:59]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> One sec, I try to find the jira ticket</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> <a href="https://jira.secondlife.com/browse/MISC-632">https://jira.secondlife.com/browse/MISC-632</a></td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> here</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> add a particles window in the building tools</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> cool, looking</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> I think it could be very usefull</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> hi q</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> annelin</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Hi, Gigs.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> Hello :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:05]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> annelin, I'm wondering why that jira doesn't seem to have been imported into our internal tool. looking</td></tr>
<tr><td bgcolor="#d0d0ff">[8:05]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> ok</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> By the way, I'm very sad because you don't translate the viewer in french, not entierly)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> it's being worked on :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> Lot of french people are lost in tools</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> That's another area of interest -- we just had an internationalization meeting last week</td></tr>
<tr><td bgcolor="#d0d0ff">[8:07]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Gigs, were you there? I had to leave early.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:07]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> No, but Steve's UI roadmap includes moving more of the strings to XUI</td></tr>
<tr><td bgcolor="#d0d0ff">[8:07]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> and a lot of the spots are already marked in the code</td></tr>
<tr><td bgcolor="#d0d0ff">[8:07]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Oh yeah. I was getting annoyed about one of them on Friday.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:07]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> hehe</td></tr>
<tr><td bgcolor="#d0d0ff">[8:08]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> yeah there's still a good amount of stuff needing to be moved</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> Residents can help for the internationalization</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> but hey don't know how to help</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> they*</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> that's true on the code side too, if we had more clear XUI guidelines we could easily move strings to XUI</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> right now, it's hard even for us...but a number of us are now thinking about the problem.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> ok</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Gigs, XUI reorganization is what I'm working on right now.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> cool</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> whay is XUI ?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> But it's a goal for the quarter</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> XUI is a way to take the strings out of the code Annelin, so they can be translated</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> ok</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> XUI is the description of the user interface, which *should* (but doesn't) include all of the text strings</td></tr>
<tr><td bgcolor="#d0d0ff">[8:11]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> We're part way toward easy translation, but there are still issues.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:11]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> If I could change the topic, Q do you know much about 3D picking code? :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:11]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I'm arm deep in that project right now hehe</td></tr>
<tr><td bgcolor="#d0d0ff">[8:12]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> the picking in the viewer is pretty messy and I'm trying to clean it up a lot</td></tr>
<tr><td bgcolor="#d0d0ff">[8:12]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I know about 3D picking in general, but haven't looked at it in the viewer yet.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:12]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> What's going on?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:13]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> well, the picking right now is sorta a mess.. we've got one place to pick a UV coord off a face, another place to determine the picked offset from the object center, and yet another place to pick just the object</td></tr>
<tr><td bgcolor="#d0d0ff">[8:14]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> the UV picking uses a gradient rendered on the face, the offset picking uses a traced ray unprojected, and the object picking uses indexed colors</td></tr>
<tr><td bgcolor="#d0d0ff">[8:14]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> All useful techniques. :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:14]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> heh yeah, I'm just not sure all three are needed :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:14]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> But I understand you'd like to be thinking about unifying them.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:15]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Still, though, for performance reasons I'm not sure that it's efficient to eliminate any of them!</td></tr>
<tr><td bgcolor="#d0d0ff">[8:15]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> yeah, well this all started in that I wanted to fix the camera zooming on hollow prims, but it's grown from there</td></tr>
<tr><td bgcolor="#d0d0ff">[8:16]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> heh, well if all three were clean implementations we'd probably want to keep them, but what I've told you really doesn't express just how messy this part of the client code is :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:16]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> /q wishes he had a "rolls eyes" gesture</td></tr>
<tr><td bgcolor="#d0d0ff">[8:16]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> it's all... 25 page long functions with these algorithms buried in them</td></tr>
<tr><td bgcolor="#d0d0ff">[8:16]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> not general use methods hehe</td></tr>
<tr><td bgcolor="#d0d0ff">[8:17]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> sigh. how far along are you?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:17]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> well, I've been able to eliminate about 1000 lines of code, there was a huge function to calculate camera focus minimum distance, which can be eliminated with better picking</td></tr>
<tr><td bgcolor="#d0d0ff">[8:18]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> it seems the picking code is ... almost obcessed with shifting the pick point toward the center of the picked object.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:18]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I can't figure out why you'd want to shift the point toward the center like that</td></tr>
<tr><td bgcolor="#d0d0ff">[8:18]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I don't see any other place in the code that relies on the pick being within the object extents really</td></tr>
<tr><td bgcolor="#d0d0ff">[8:19]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> That explains some behavior of camera motion I always thought was odd.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:19]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> yeah</td></tr>
<tr><td bgcolor="#d0d0ff">[8:19]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> that kinda thing is what I'm trying to work out</td></tr>
<tr><td bgcolor="#d0d0ff">[8:19]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> also, there's entirely different picking code for avatars vs objects, I'm going to try to unify that some</td></tr>
<tr><td bgcolor="#d0d0ff">[8:20]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> So as you know, we're not yet very good at accepting patches. Some of us are trying to improve that.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:20]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> since really, even though the avatar doesn't hit the same as an object, I'm not sure it justifies completely separate code</td></tr>
<tr><td bgcolor="#d0d0ff">[8:20]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> But the bigger your changes, the harder it is to accept them, especially right now.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:20]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> hehe</td></tr>
<tr><td bgcolor="#d0d0ff">[8:20]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> well, this part of the client is so crufty, if my patch works, I suspect it will be an easy sell</td></tr>
<tr><td bgcolor="#d0d0ff">[8:21]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> it looks like no one has touched this stuff since 2003</td></tr>
<tr><td bgcolor="#d0d0ff">[8:21]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> ^^</td></tr>
<tr><td bgcolor="#d0d0ff">[8:21]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yes, but my worry is that it collides with something else we're trying to do internally, and then we could lose it.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:21]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> is someone else messing with the picking?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:22]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Esp. since we now have the viewer cleanup project going. I don't think so...although it's been something I was thinking about.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:22]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I haven't touched it yet, and wouldn't be likely to for a couple of months.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:22]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Is there a JIRA on this?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:23]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> kinda, this was all started under a Jira to make zooming inside hollow prims not suck.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:23]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> ok...is that VWR-1286?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:24]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> <a href="https://jira.secondlife.com/browse/VWR-1286">https://jira.secondlife.com/browse/VWR-1286</a></td></tr>
<tr><td bgcolor="#d0d0ff">[8:24]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> yeah</td></tr>
<tr><td bgcolor="#d0d0ff">[8:24]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I had things almost working fine at one point, but one little nagging issue has uncovered a lot more breakage in the current code.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:25]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> This is, I imagine, a bit risky regarding changes to current behavior.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:25]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I can avoid refactoring everything.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:25]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> That will help!</td></tr>
<tr><td bgcolor="#d0d0ff">[8:25]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> There's really two main functions I'd probably need to touch.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:26]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> Though I have to say, SL will never really move forward as an open source project if you can't take larger patches. :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:26]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Keep me posted on this, ok? I'll probably want to adopt it, as it's a point of pain for me.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> k</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yes, we know. We're thinking about it pretty hard.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> There's only one regression I have planned right now, and it's a minor one</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> How many lines of code has SL ?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> the viewer</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Trying to put systems in place that can let us do that, while not adding too much drag to our internal processes</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> right now if you "pan into" the selected prim the viewer will push your camera out of it. However it'll happily pan other prims through your near clip</td></tr>
<tr><td bgcolor="#d0d0ff">[8:28]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I do plan to have a small change to that, in that you can pan the current selection through near clip.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:28]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> this shouldn't be confusing since the viewer already lets you pan into other objects, just not the current one.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:29]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> this has some benefits too</td></tr>
<tr><td bgcolor="#d0d0ff">[8:29]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> if you lose an attachment inside your avatar, this will make it easier to get out :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:29]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> annelin, I haven't added up just the viewer, but over all of SL there are about 1 million lines of code.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:29]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> ok thank you</td></tr>
<tr><td bgcolor="#d0d0ff">[8:29]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> newview$ cat *.cpp | wc -l 276350</td></tr>
<tr><td bgcolor="#d0d0ff">[8:30]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> there's just the main viewer</td></tr>
<tr><td bgcolor="#d0d0ff">[8:30]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> without counting llimage or common</td></tr>
<tr><td bgcolor="#d0d0ff">[8:30]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> So that's about what you'd expect for a large graphics application.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:31]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Large, but manageable.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:31]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I suspect we could drop about 20KLOC :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:31]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> with a good refactoring</td></tr>
<tr><td bgcolor="#d0d0ff">[8:31]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Gigs, it's a good day when I write negative lines of code. :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:31]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> hehe</td></tr>
<tr><td bgcolor="#d0d0ff">[8:32]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Ok, so I'll keep an eye on this one.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:32]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> cool, yeah I'll post the patch to SLDEV when I get the picking sorted in a way that really works 100% of the time</td></tr>
<tr><td bgcolor="#d0d0ff">[8:33]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Sounds great</td></tr>
<tr><td bgcolor="#d0d0ff">[8:33]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I'm being extra picky (as it were) on this one because it's something people use all day every day</td></tr>
<tr><td bgcolor="#d0d0ff">[8:33]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I really want to get the regressions down to 0</td></tr>
<tr><td bgcolor="#d0d0ff">[8:33]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> ;-) Please do -- everything you can do makes it easier to take internally. Also, consider writing test plans as part of the submission.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:33]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> (Except that bounding box constraint)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:34]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> sure, the camera has about a dozen or two test cases</td></tr>
<tr><td bgcolor="#d0d0ff">[8:34]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> hehe</td></tr>
<tr><td bgcolor="#d0d0ff">[8:34]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> it's not an easy part of the code to change</td></tr>
<tr><td bgcolor="#d0d0ff">[8:34]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> but I'm hoping in the end this will solve a lot of problems</td></tr>
<tr><td bgcolor="#d0d0ff">[8:35]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> many of the camera movement bugs filed</td></tr>
<tr><td bgcolor="#d0d0ff">[8:35]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Me too.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:35]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Ok, sun's up and I should probably get moving.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:35]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Thank you both for coming!</td></tr>
<tr><td bgcolor="#d0d0ff">[8:35]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:35]</td><td bgcolor="#d0ffd0">Annelin Corrigible</td><td bgcolor=#ffffff> that was a pleasure</td></tr>
<tr><td bgcolor="#d0d0ff">[8:35]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> alright</td></tr>
<tr><td bgcolor="#d0d0ff">[8:35]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> later!</td></tr>
<tr><td bgcolor="#d0d0ff">[8:35]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> For me too. See you!</td></tr>
<tr><td></td><td></td><td><font color="blue"></font></td></tr>
</table>

User:Q Linden/Office Hours/2007-10-01

2007-10-01T21:51:50Z

<table border="0">
<tr bgcolor="yellow"><td width="7%">Time</td><td width="15%">Speaker</td><td>Remarks</td></tr>
<tr><td bgcolor="#d0d0ff">[7:37]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> Hi Q, Hi Gigs</td></tr>
<tr><td bgcolor="#d0d0ff">[7:37]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> hey all</td></tr>
<tr><td bgcolor="#d0d0ff">[7:37]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> hi</td></tr>
<tr><td bgcolor="#d0d0ff">[7:37]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> got dark while I wasn't looking</td></tr>
<tr><td bgcolor="#d0d0ff">[7:38]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> hehe</td></tr>
<tr><td bgcolor="#d0d0ff">[7:38]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I'm probably not up to doing more than that off the cuff!~</td></tr>
<tr><td bgcolor="#d0d0ff">[7:38]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I just got up so it might take me a few minutes to get up to speed :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:38]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> yeah...since I'm on the east coast this is easy for me</td></tr>
<tr><td bgcolor="#d0d0ff">[7:39]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> Same here Q</td></tr>
<tr><td bgcolor="#d0d0ff">[7:39]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I thought that there should be some early hours for people on european time</td></tr>
<tr><td bgcolor="#d0d0ff">[7:39]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> so do you folks have things you'd like to talk about in particular?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:40]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> I've not been to your office hour before so I thought I'd come and listen or see what was on your agenda today : )</td></tr>
<tr><td bgcolor="#d0d0ff">[7:40]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> well, I'm a relatively new Linden -- about 3 months now -- and I'm just finishing up my, well, assimilation</td></tr>
<tr><td bgcolor="#d0d0ff">[7:40]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:41]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> Congrats : )</td></tr>
<tr><td bgcolor="#d0d0ff">[7:41]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I've decided to focus on open source and viewer issues</td></tr>
<tr><td bgcolor="#d0d0ff">[7:41]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> cool</td></tr>
<tr><td bgcolor="#d0d0ff">[7:41]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> well I've got plenty I could talk about if you don't have any plans in particular :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:41]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> so I'll be joining "studio shiny"</td></tr>
<tr><td bgcolor="#d0d0ff">[7:41]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> In terms of viewer UI</td></tr>
<tr><td bgcolor="#d0d0ff">[7:41]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> Would viewer issues include features?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Eventually, yes, but at the moment I'm thinking about some viewer refactoring, particularly around XUI</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> me too</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Although I have to talk with the team about how best to go about that</td></tr>
<tr><td bgcolor="#d0d0ff">[7:42]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> my angle on that is that it's something the community can really help out with, but we have a lack of details about what exactly needs to be accomplished</td></tr>
<tr><td bgcolor="#d0d0ff">[7:43]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> obviously all those XUI:translate tags need to go away</td></tr>
<tr><td bgcolor="#d0d0ff">[7:43]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> heh</td></tr>
<tr><td bgcolor="#d0d0ff">[7:43]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I really want to get our translation process worki8ng right</td></tr>
<tr><td bgcolor="#d0d0ff">[7:43]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> but other than that... kinda lost as to where things are heading. A lot of the community is chomping the bit to get to client automation... I think the automation would be best layered right on top of the UI callback level</td></tr>
<tr><td bgcolor="#d0d0ff">[7:43]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> the translations lag too much</td></tr>
<tr><td bgcolor="#d0d0ff">[7:44]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I don't know if you saw the thing with Gareth on IRC</td></tr>
<tr><td bgcolor="#d0d0ff">[7:44]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I know...I really want client automation too. Yes, I saw some of it.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:44]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> yeah I think that if we do this right, it can be a useful tool for QA too</td></tr>
<tr><td bgcolor="#d0d0ff">[7:44]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I love python, but I think the longterm direction probably needs to be Mono</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I think that Gareth's work will be educational but it may not be the correct long-term solution</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I'm not so sure about that, but if the API is straightforward enough it might be easy to link in multiple front ends.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> well "easy"</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Hence the reason I was nudging him in the direction of SWIG</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> in scare quotes</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> hehe</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> There are API directions that I think would probably be worth experimenting with.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I'd imagine we'd pick and choose from an experimental implementation.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:47]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> one concern I have with mono is that the low end computers people run SL on... not sure they could deal with a heavy VM in the background in addition to another copy of mozlib, etc :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:47]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> So any work in this area should probably be done in smallish bits</td></tr>
<tr><td bgcolor="#d0d0ff">[7:47]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> mostly a footprint concern</td></tr>
<tr><td bgcolor="#d0d0ff">[7:47]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I have to confess that I don't know enough about the mono implementation to share your concern yet.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:47]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> it may not be an issue either</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> just something that came to mind as a potential problem</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> One of my areas of interest, though, is education, so I want to make sure that there are clients that could run SL on older and/or slower boxes</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> For example, I'm involved with the One Laptop PEr Child project</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> OLPC</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I hope that a few months from now we'll be able to have some sort of viewer that could run on that platform, even if it's not 3d</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> hehe, yeah</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> until they firewall SL for being a porn site</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> woof</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor="#d0ffd0">goes for the low blow</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> Is there still talk of a separate education grid?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Well, my wife actually works for OLPC, so maybe I can have some influence there. :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Savannah, I don't know. It's not "talk" that I've heard, but there's a lot I haven't heard.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Where did you hear that? I can try to find out.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> I missed the meeting about it in world. I can get the notes though.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I always saw the all ages area as an educational thing</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> if that ever happens :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> It would make sense. There are uses for SL that we can't support, because we don't let people under 13 on .</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> yeah we have issues there with SL Views and such too</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> Yes I see a lot of Pros and some Cons for it. Pros for academics and cons for the rest of us if Educators left the main grid.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> Catherine Berry is trying to participate in Views and the Arch Working Group but is kinda locked out of it all</td></tr>
<tr><td bgcolor="#d0d0ff">[7:52]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Why is she locked out?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:52]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> because shes like 16</td></tr>
<tr><td bgcolor="#d0d0ff">[7:52]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Ah, right. Yes, ok, now I know why I've seen the name.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:52]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> she was with us in SF at the meetings</td></tr>
<tr><td bgcolor="#d0d0ff">[7:52]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> but now that that's over, she's missing a lot of it</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yeah, we know we don't have a perfect answer there yet. It's been a topic for discussion frequently.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> Too bad there can't be a Teen translation of information forwarded to the Teen grid internally.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> It's more of a dialog anyway, just forwarding information to them wouldn't be very complete either.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Is she also prevented from participating on the wiki?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I'm not sure about that</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I don't know our policies there</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> the mailing lists are open I think though</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> yeah, maybe she wants to get on SLDev</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> but really missing the in-world part I can see how you might just give up</td></tr>
<tr><td bgcolor="#d0d0ff">[7:55]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Understood.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:55]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Gigs, what areas of OS have you been working on?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:56]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> Q back to the technical side of things, I'd really like to do something like a work breakdown on the UI Roadmap, making small chunks of tasks that Open Source could accomplish in limited amounts of time</td></tr>
<tr><td bgcolor="#d0d0ff">[7:56]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I've been fixing bugs and doing small features to help with pain points (mainly my own) :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> My latest patches are better terraform tools, a more flexible snapshot tool, and a couple others</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Ok, I'm listening. I think what you're saying is you'd like more explicit guidance as to what we need and in what order?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> for the UI roadmap, yeah</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> you familair with a WBS in PM terms?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> I'd like to see snap off and enlargement of the Web tab, with browser forward and back tabs.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> WBS meaning -- work breakdown schedule?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> (In the profile)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> yeah work breakdown structure</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> http://www.hyperthot.com/pm_wbs.htm</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> which would help with your program Q.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> (not the best site, just first hit on google)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> would help me with which program?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:59]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> Lap tops for every child. When you are seeking to run a slower connection or client, using the profile web tab allows for browser use without loading down the system. Its just that a page is so small there it becomes time consuming to use other than watching youtube videos.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:00]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Gigs, I've never seen a work chart in that format before. Seems like everyone I've ever worked with has used Gantt layouts</td></tr>
<tr><td bgcolor="#d0d0ff">[8:00]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Ah, right</td></tr>
<tr><td bgcolor="#d0d0ff">[8:00]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> the WBS is the input to the Gantt chart</td></tr>
<tr><td bgcolor="#d0d0ff">[8:00]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> Gantt schedules the WBS tasks</td></tr>
<tr><td bgcolor="#d0d0ff">[8:00]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> but with open source, we probably want to stop short of gantt probably :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> mainly concentrate on ordering of tasks rather than scheduling</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Is there an implied dependency in those task items I see there?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> yes</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> the leaf nodes are prereqs to the higher nodes</td></tr>
<tr><td bgcolor="#d0d0ff">[8:02]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> it captures the dependancy in addition to breaking down the tasks into small units that can be accomplished in a day or so</td></tr>
<tr><td bgcolor="#d0d0ff">[8:02]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> or at least into tasks that are straightforward enough</td></tr>
<tr><td bgcolor="#d0d0ff">[8:02]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Savannah, I see what you're getting at. I'm thinking that a thin client probably would be *mostly* browser. But that's just my own thought, not a Linden Pronouncement.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I'm not saying this WBS format is the way to go, it's just an example from the project management world of the sort of thing we are going to need to do to get open source developers working in the same direction IMO</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Gigs, have you found that open source can be managed that closely?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> it's not about management as much as showing people how we can get there from here, a "marketing tool"</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> if we can say "here's how we get client automation in a clean way, and here's what has to happen to get there" then people will be eager to put their name next to the small lists tasks</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> (that's the idea at least) :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I see, ok. One of the things we're learning is how best to engage the community. We really do want to do it right, and I think we now have a bunch of people pulling in the same direction.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:05]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> other open source projects generally do make these detailed tasks lists</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> in terms of what needs to happen to accomplish larger goals</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Ok...I think we're getting there.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Savannah, I see Orientation Station on your profile. Can you tell me more about it?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> it's usually done in terms of milestones being the mid level nodes</td></tr>
<tr><td bgcolor="#d0d0ff">[8:08]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> ok. I'm literally just starting in this area today, so I'll probably have more to say about this in the coming weeks.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:08]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> cool :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> Hi Rev</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Gig, what do you plan to do once you have client-side scripting?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> hello Sav, and Q Linden ^^</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> The possibilities are almost limitless :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> AIs NPCs, sex bots, etc :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> hi, revolution</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> lol Gigs , dont they exist already i write bots already touching the code base with libsl</td></tr>
<tr><td bgcolor="#d0d0ff">[8:11]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> yeah, but it's not easy to package that up and sell it</td></tr>
<tr><td bgcolor="#d0d0ff">[8:11]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Rev, how are you finding libsl?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:11]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> well its not too bad but its missing alot , im really waiting for miller to anounce server code is released under GPL</td></tr>
<tr><td bgcolor="#d0d0ff">[8:12]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> but i do have question about that ^^ how are you going to release server code with commerical code</td></tr>
<tr><td bgcolor="#d0d0ff">[8:12]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I was saying earlier that I'm newly working on the open source side of SL. One of the things I'm thinking about is working on that.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:12]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> becuase you have wqindlight, havok and many other sdks which are commerical</td></tr>
<tr><td bgcolor="#d0d0ff">[8:12]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> are you planning to write an alt physics engine</td></tr>
<tr><td bgcolor="#d0d0ff">[8:12]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> or something like ODE</td></tr>
<tr><td bgcolor="#d0d0ff">[8:13]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> which is prety much an free open source physics engine , even its not up to specs with havok 4 /5 it does a fair job</td></tr>
<tr><td bgcolor="#d0d0ff">[8:13]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Well, yeah...the server release is still many months away because of issues like that. We have to solve a number of things, including distributed trust, and how to handle libraries.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:13]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> you planning to prepack dlls or libs of your custom havok hehe</td></tr>
<tr><td bgcolor="#d0d0ff">[8:13]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> look at what happened to vale few years ago</td></tr>
<tr><td bgcolor="#d0d0ff">[8:14]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> you dont want to make that mistake</td></tr>
<tr><td bgcolor="#d0d0ff">[8:14]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> We will probably have to do something like that, so that there's a standard API and then plugin physics engines or something.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:14]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> What happened to vale? That doesn't ring bells with me.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:14]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> and i do know in the end, second life wont be a game no more it be a platform, look at apache httpd project , we could see second life up there and in the long run the community will help</td></tr>
<tr><td bgcolor="#d0d0ff">[8:15]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> but personally linden labs right now are very poor in promoting open source</td></tr>
<tr><td bgcolor="#d0d0ff">[8:15]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> We know, but we're ramping up real fast, because now there are a bunch of us that actually care.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:15]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> becuause im aways fixing , sending patches to you guys and ticket left open for months</td></tr>
<tr><td bgcolor="#d0d0ff">[8:16]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> and unassigned im aways having to track lindens down in world saying hey look at this ^^ import plz</td></tr>
<tr><td bgcolor="#d0d0ff">[8:16]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yeah, we know. THat's partly why I'm joining that team. Part of the problem is making sure that what you're working on is what we're ready to accept.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:17]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> We were just talking earlier about us trying to be better about publishing our roadmap, broken down so that os devs can help</td></tr>
<tr><td bgcolor="#d0d0ff">[8:17]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> Revolution what is an example of this?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:17]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> oh, btw, is everyone here OK if I publish this transcrpt?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:17]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> yeah</td></tr>
<tr><td bgcolor="#d0d0ff">[8:17]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> yes</td></tr>
<tr><td bgcolor="#d0d0ff">[8:17]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> with the new website underway too het grid , open source needs to be pushed , people need to know that the source code is there, open source is very big if its web based or c++ many residnets in world can code , or some have some history. maybe blogging open source more often would help too make people relise they can pitch in and do there part</td></tr>
<tr><td bgcolor="#d0d0ff">[8:18]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> yes you may ^^</td></tr>
<tr><td bgcolor="#d0d0ff">[8:18]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> As I get up to speed I'll be blogging more, and you'll start seeing me more on SLDev and IRC</td></tr>
<tr><td bgcolor="#d0d0ff">[8:19]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> "more" meaning > 0 ;-)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:19]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> Revolution I'm looking at the pending patch list, I don't see any of yours</td></tr>
<tr><td bgcolor="#d0d0ff">[8:20]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> Can you send me one that you are talking about?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:21]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> thats would be great, becuase linden labs pushing really hard right now, look we have havok on beta grid now, mono is matter of weeks behind and windlight will follow and once the server code is released we like to see the community involved too making this stable, i know linden labs rather add new features then fix bugs, becuase most of the bugs are umbrella effects bugs, either same bugs comming up again and again or bugs being reopened and if the community is involved we could fix but linden labs really needs to look at jira more often and not just importing or closing at office hours but doing the same off world and go though them more and get them to a level where improvmenbts in the viewer or server side which will imporve users expierence</td></tr>
<tr><td bgcolor="#d0d0ff">[8:22]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> there many on there as me or as my alt ^^</td></tr>
<tr><td bgcolor="#d0d0ff">[8:22]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> and i had to track down rob , ben , torley many times</td></tr>
<tr><td bgcolor="#d0d0ff">[8:23]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> i go over current open reports and update, patch or close them if they already been solved by LL</td></tr>
<tr><td bgcolor="#d0d0ff">[8:23]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> Revolution don't forget to use the "patch attached" flag, or it won't get triaged with priority.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:23]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Well, most devs would rather add features than fix bugs, but at this point I think I can safely say that LL "gets it" -- Havok is really about stability, and most everyone on the team is focused on stability and long-term growth issues. Anyone who wants to add features without a corresponding increase in stability gets spanked. :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:23]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> awww i never knew that</td></tr>
<tr><td bgcolor="#d0d0ff">[8:23]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> hehe yeah that might be part of the problem there :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:24]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> And we know we haven't been good about importing patches -- we're rather significantly renovating our internal processes to make that easier.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:25]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> A couple of people like Soft and Sardonyx have been pushing us hard</td></tr>
<tr><td bgcolor="#d0d0ff">[8:25]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> are there any plans of putting goo fence up a notch too, personally i find andrew security measure dont seem to be all that now , everyone released now how to defeat it, i defeated his goo fence with one line of code you dont have to be no expert in lsl and hopefully havok will reduce alot too with alot of common grifer attacks</td></tr>
<tr><td bgcolor="#d0d0ff">[8:25]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> And I'm adding my weight to the pile-on.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:25]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> i bet</td></tr>
<tr><td bgcolor="#d0d0ff">[8:26]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> We're all optimistic that havok is gonna make life a lot harder for the griefers.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:26]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I have a concern there Q :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:26]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Gigs: which "there"?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:26]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> Right now if you physics lag a region it falls down and rolls back, in Havok4 you could make a region sit at 0.1 TD forever.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> I'm not sure that is a net improvement per-se</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Well...rollback creates significant problems with inventory loss</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> are there plans of implementing more of havok features down the line , shame to pay a huge costs in there licence and not add all the benfits of havok, like ragdoll, hinge and joint movements and just wrapping basic physics we have now with the stablity of sl physics</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> So we really hate to rollback.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:27]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> so much could be done , and would help residnets be more creative, use of less prims</td></tr>
<tr><td bgcolor="#d0d0ff">[8:28]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Rev, yes...but as our residents are fond of reminding us, we need to get the stability part right first. :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:28]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> One plus is even though the region goes down to .2 TD or whatever, you can still move :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:28]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> the region doesn't become completely unresonsive at least</td></tr>
<tr><td bgcolor="#d0d0ff">[8:28]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Exactly</td></tr>
<tr><td bgcolor="#d0d0ff">[8:29]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> wow thats a great improvment , i did notice alot of bugs still in beta grid even basic swing effects dont seem to work too great where they would normally under havok 1 or this code we are using now</td></tr>
<tr><td bgcolor="#d0d0ff">[8:29]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> But this is why we're doing it on the beta grid. Hopefully we can tune things so that even that kind of thing is less of an issue.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:29]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> revolution yeah basic machines like hinges and seesaws don't work as well in havok4, but I'd be willing to give that up :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:29]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I sit across from Sidewinder, who's been shepherding this project, and he wants it to be right!</td></tr>
<tr><td bgcolor="#d0d0ff">[8:29]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> its been a really long road with havok, and i can imagine its been really complex adding something like this</td></tr>
<tr><td bgcolor="#d0d0ff">[8:30]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> That's what beta's for. Part of what we've been trying to do is to do a better job of integration so that we can update the physics more easily down the road. That's caused some of the delay.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:30]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> yeah, that'll be even more critical when you are talking about potentially open sourcing things :)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:31]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> well the biggest problem i find with beta grid maybe one of the reasons you guys introduced RC viewers , not many people seem to want to use the beta grid accept when the grid down for maintence</td></tr>
<tr><td bgcolor="#d0d0ff">[8:31]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> i only use it myself to make sure my products still work ^^</td></tr>
<tr><td bgcolor="#d0d0ff">[8:31]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Right. Yagottawanna...which is fine. We don't want the whole world in there, just those willing to put up with a little pain.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:32]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> So it's 8:30, and I've got to run. ANy last remarks?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:32]</td><td bgcolor="#d0ffd0">Gigs Taggart</td><td bgcolor=#ffffff> HIPPOS!</td></tr>
<tr><td bgcolor="#d0d0ff">[8:32]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> lol</td></tr>
<tr><td bgcolor="#d0d0ff">[8:32]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> Nice meeting you Q</td></tr>
<tr><td bgcolor="#d0d0ff">[8:32]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> we know that , but even beta grid not many people are aware , feature like this are major get them to try it , there are many developers in world, like you say we create the world , you guys just give us the tools ^^</td></tr>
<tr><td bgcolor="#d0d0ff">[8:32]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> That's what we're after. Thank you all for coming. Pass the word!</td></tr>
<tr><td bgcolor="#d0d0ff">[8:33]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> not at all but thanks for your hard work</td></tr>
<tr><td bgcolor="#d0d0ff">[8:33]</td><td bgcolor="#d0ffd0">Revolution Perenti</td><td bgcolor=#ffffff> we have faith in you guys , good comes to those who wait</td></tr>
<tr><td bgcolor="#d0d0ff">[8:33]</td><td bgcolor="#d0ffd0">Savannah Glimmer</td><td bgcolor=#ffffff> : )</td></tr>
<tr><td bgcolor="#d0d0ff">[8:33]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Bye!</td></tr>
</table>

User:Q Linden/Office Hours/2007-09-24

2007-09-24T16:59:06Z

Q Linden: /* Transcript of Q Office Hours on Monday, 24Sep07, 7:30 AM PST */

= Transcript of Q Office Hours on Monday, 24Sep07, 7:30 AM PST =

Note: although in general, anything said during my office hours can be considered to be public, in this case there was only one other person there, and at times the chat veered into personal discussion that one of us would prefer to keep private. Those places where text was cut are marked in the transcript.

----
<table border="0">
<tr bgcolor="yellow"><td width="7%">Time</td><td width="15%">Speaker</td><td>Remarks</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Hey, Jansen</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Hiya. Hmm. First office hours?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Looks like you need to build a following. :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yup...but it wasn't well-announced. I failed to complete the wiki page properly ,and just figured it out this morning.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> No biggie...I'll get it right next time. :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:47]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Did you just trip across it, or were you looking for office hrs?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> No, I was checking office hours on the Wiki. I got up unusually early this morning and was wondering if any office hours coincided.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> cool. anything in particular on your mind?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Nope. But I have some advice. You need to set out some chairs, or let us place our own. :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> see those? Those were supposed to be my chairs for the day.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I popped 'em up there this morning. :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Ah, okay. I didn't realize.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Or since there are so few people, we can go over to my gazebo</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Maybe five or six chairs close to the campfire would seem more inviting.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> So, you're a new Linden, but how long have you been on SL?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Basic Chair</td><td bgcolor=#ffffff> Right click me and choose 'Sit Here' to sit down</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> just 2 months!</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Oh wow.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> So I'm really a n00b</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> You're even newer than me.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:52]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> What attracted you to SL in the first place?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Well, I read Snowcrash in the 90s.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Heh. As did half this world, I think.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Did you have experience with other online communities?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> And I'd heard about SL for a couple of years. It was on my list of things to check out and I finally got around to it.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> No. Not really. I played MUDs in the 90s</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Do you consider yourself a gamer?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> And beta tested and played Asheron's Call 2.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> ah, cool</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I would say yes, but I'm definitely in the camp of "SL is not a game."</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> me too...on both counts</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> but I like to know what people have for background experience</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> as a reference</td></tr>
<tr><td></td><td></td><td><font color="blue">[PERSONAL INFORMATION SNIPPED]</font></td></tr>
<tr><td bgcolor="#d0d0ff">[7:56]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Do you build stuff in SL?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I do.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Code too?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Yep.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I'd be interested in hearing your thoughts -- what works well, what doesn't.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I have definite opinions although at this early hour (I'm PST remember), I don't know if I can say much that's intelligible.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I'm putting together a list of UI enhancements I think would be good.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> We haven't invented virtual caffeine yet.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:59]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Mostly relating to the build tools.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:59]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Building is very primitive in SL. Pun not intentional.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:00]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Heh...yeah. A lot of my recent history has been spent making 3D construction tools, including tools for kids. So I care a lot about this area.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:00]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> It's one place I hope to spend some of my development energy at Linden.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:00]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> And the build editing tools are impressive as they're expressed in-world, but leave much to be desired when compared to what a professional content developer might expect from his/her tools.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yeah</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Do you have particular high points of pain?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Some of the problems are intractable at the moment. Such as the parent-child relationships of linked sets. I.e. one root only.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> (when you say you're putting together a list, how do you plan to share that list?)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:02]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Through the JIRA.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:02]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> excellent</td></tr>
<tr><td bgcolor="#d0d0ff">[8:02]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> do you know about the SL Dev mailing list for open source discussions?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> ...that would require major re-working of the SL object system. To smaller issues like the lack of ability to change point of rotation when rotating an object or linked set.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yup, that's a problem I encountered this morning</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I'm vaguely aware of SL Dev group activity, but I'm not directly involved.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I've attended one or two open source office hours.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Who else's have you been to?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:05]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> And I'm familiar with Dale Glass' work because I see him at half the office hours I attend.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:05]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> yup, he's been pretty involved, at least I've seen him around quite a bit</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Rob, Lindie, Benjamin bug triages. Qarl. Zero. Torley. Blue.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> oh, by the way...since this has ended up being a private session, is it OK with you if I post the transcript?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:07]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> And I'm actually a bit surprised not to see Wyn Galbraith here. She seems to usually hit all the office hours I attend, although that may have something to do with you posting the hours late.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:07]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> If you like.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:08]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I'd just like to establish a tradition of being open about everything that happens in my office hours</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> There were a couple of people who said they'd come if I held office hours, but I think that the late notice was a problem.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> More than likely that was it.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> So, what, in fact, is your role at LL? Boston. You were part of the Windlight team that came over?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:11]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> No, actually. I was the first non-Windlight dev hired in Boston. I'm a game developer who became interested in SL. I'm just finishing up my "training" phase and looking around for what I should be spending time on now. User content creation tools is one possible area, as is architecture.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:12]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> architecture meaning the long-term system design</td></tr>
<tr><td></td><td></td><td><font color="blue">[PERSONAL INFORMATION SNIPPED]</font></td></tr>
<tr><td bgcolor="#d0d0ff">[8:16]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> C++ and OpenGL?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:16]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> My skillz? That and Python, Java if you make me.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:17]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> That doesn't parse unambiguously -- I love python, not so much Java</td></tr>
<tr><td></td><td></td><td><font color="blue">[PERSONAL INFORMATION SNIPPED]</font></td></tr>
<tr><td></td><td></td><td><font color="blue"></font></td></tr>
</table>

----

User:Q Linden/Office Hours/2007-09-24

2007-09-24T16:49:56Z

Q Linden: New page: = Transcript of Q Office Hours on Monday, 24Sep07, 7:30 AM PST = ---- <table border="0"> <tr bgcolor="yellow"><td width="7%">Time</td><td width="15%">Speaker</td><td>Remarks</td></tr> <tr...

= Transcript of Q Office Hours on Monday, 24Sep07, 7:30 AM PST =

----
<table border="0">
<tr bgcolor="yellow"><td width="7%">Time</td><td width="15%">Speaker</td><td>Remarks</td></tr>
<tr><td bgcolor="#d0d0ff">[7:45]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Hey, Jansen</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Hiya. Hmm. First office hours?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Looks like you need to build a following. :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yup...but it wasn't well-announced. I failed to complete the wiki page properly ,and just figured it out this morning.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:46]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> No biggie...I'll get it right next time. :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:47]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Did you just trip across it, or were you looking for office hrs?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> No, I was checking office hours on the Wiki. I got up unusually early this morning and was wondering if any office hours coincided.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> cool. anything in particular on your mind?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:48]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Nope. But I have some advice. You need to set out some chairs, or let us place our own. :)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> see those? Those were supposed to be my chairs for the day.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I popped 'em up there this morning. :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:49]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Ah, okay. I didn't realize.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Or since there are so few people, we can go over to my gazebo</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Maybe five or six chairs close to the campfire would seem more inviting.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> So, you're a new Linden, but how long have you been on SL?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:50]</td><td bgcolor="#d0ffd0">Basic Chair</td><td bgcolor=#ffffff> Right click me and choose 'Sit Here' to sit down</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> just 2 months!</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Oh wow.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> So I'm really a n00b</td></tr>
<tr><td bgcolor="#d0d0ff">[7:51]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> You're even newer than me.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:52]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> What attracted you to SL in the first place?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Well, I read Snowcrash in the 90s.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Heh. As did half this world, I think.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Did you have experience with other online communities?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> And I'd heard about SL for a couple of years. It was on my list of things to check out and I finally got around to it.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:53]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> No. Not really. I played MUDs in the 90s</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Do you consider yourself a gamer?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> And beta tested and played Asheron's Call 2.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> ah, cool</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I would say yes, but I'm definitely in the camp of "SL is not a game."</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> me too...on both counts</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> but I like to know what people have for background experience</td></tr>
<tr><td bgcolor="#d0d0ff">[7:54]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> as a reference</td></tr>
<tr><td></td><td></td><td><font color="blue">[PERSONAL INFORMATION SNIPPED]</font></td></tr>
<tr><td bgcolor="#d0d0ff">[7:56]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Do you build stuff in SL?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I do.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Code too?</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Yep.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:57]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I'd be interested in hearing your thoughts -- what works well, what doesn't.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I have definite opinions although at this early hour (I'm PST remember), I don't know if I can say much that's intelligible.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> :-)</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I'm putting together a list of UI enhancements I think would be good.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:58]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> We haven't invented virtual caffeine yet.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:59]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Mostly relating to the build tools.</td></tr>
<tr><td bgcolor="#d0d0ff">[7:59]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Building is very primitive in SL. Pun not intentional.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:00]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Heh...yeah. A lot of my recent history has been spent making 3D construction tools, including tools for kids. So I care a lot about this area.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:00]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> It's one place I hope to spend some of my development energy at Linden.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:00]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> And the build editing tools are impressive as they're expressed in-world, but leave much to be desired when compared to what a professional content developer might expect from his/her tools.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yeah</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Do you have particular high points of pain?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Some of the problems are intractable at the moment. Such as the parent-child relationships of linked sets. I.e. one root only.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:01]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> (when you say you're putting together a list, how do you plan to share that list?)</td></tr>
<tr><td bgcolor="#d0d0ff">[8:02]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Through the JIRA.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:02]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> excellent</td></tr>
<tr><td bgcolor="#d0d0ff">[8:02]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> do you know about the SL Dev mailing list for open source discussions?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> ...that would require major re-working of the SL object system. To smaller issues like the lack of ability to change point of rotation when rotating an object or linked set.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Yup, that's a problem I encountered this morning</td></tr>
<tr><td bgcolor="#d0d0ff">[8:03]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I'm vaguely aware of SL Dev group activity, but I'm not directly involved.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> I've attended one or two open source office hours.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:04]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> Who else's have you been to?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:05]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> And I'm familiar with Dale Glass' work because I see him at half the office hours I attend.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:05]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> yup, he's been pretty involved, at least I've seen him around quite a bit</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> Rob, Lindie, Benjamin bug triages. Qarl. Zero. Torley. Blue.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:06]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> oh, by the way...since this has ended up being a private session, is it OK with you if I post the transcript?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:07]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> And I'm actually a bit surprised not to see Wyn Galbraith here. She seems to usually hit all the office hours I attend, although that may have something to do with you posting the hours late.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:07]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> If you like.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:08]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> I'd just like to establish a tradition of being open about everything that happens in my office hours</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> There were a couple of people who said they'd come if I held office hours, but I think that the late notice was a problem.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:09]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> More than likely that was it.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:10]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> So, what, in fact, is your role at LL? Boston. You were part of the Windlight team that came over?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:11]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> No, actually. I was the first non-Windlight dev hired in Boston. I'm a game developer who became interested in SL. I'm just finishing up my "training" phase and looking around for what I should be spending time on now. User content creation tools is one possible area, as is architecture.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:12]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> architecture meaning the long-term system design</td></tr>
<tr><td></td><td></td><td><font color="blue">[PERSONAL INFORMATION SNIPPED]</font></td></tr>
<tr><td bgcolor="#d0d0ff">[8:16]</td><td bgcolor="#d0ffd0">Jansen Miles</td><td bgcolor=#ffffff> C++ and OpenGL?</td></tr>
<tr><td bgcolor="#d0d0ff">[8:16]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> My skillz? That and Python, Java if you make me.</td></tr>
<tr><td bgcolor="#d0d0ff">[8:17]</td><td bgcolor="#d0ffd0">Q Linden</td><td bgcolor=#ffffd0> That doesn't parse unambiguously -- I love python, not so much Java</td></tr>
<tr><td></td><td></td><td><font color="blue">[PERSONAL INFORMATION SNIPPED]</font></td></tr>
<tr><td></td><td></td><td><font color="blue"></font></td></tr>
</table>

----

Template:Office Hours

2007-09-24T14:37:51Z

Q Linden: /* Displaying your Office Hours */

<includeonly>{{#ifeq:{{#var:Office_Hours_Render_Mode}}|tr|{{!}}-style="vertical-align:top;"
{{!}} style="white-space:nowrap;vertical-align:top;text-align:center;" {{!}}
[[User:{{{Resident|}}}|{{{Resident|No Resident specified}}}]]
{{!}} style="vertical-align:top;text-align:left;" {{!}}
{{{times|no times specified}}}
{{!}} style="vertical-align:top;text-align:left;" {{!}}
{{{topics|No metadata specified}}}
{{!}} style="vertical-align:top;text-align:center;" {{!}}
{{{location|no location specified}}}|{{#if:{{{topics|}}}|<div class="summary">
{{{topics}}}
</div>|}}
{{ #if:{{{times|}}}|<div class="times">
{{{times}}}
</div>|}}
{{ #if:{{{location|}}}|<div class="location">
{{{location}}}
</div>|}}}}{{ #ifeq:{{NAMESPACE}}|User|{{ #ifeq:{{SUBPAGENAME}}|Office Hours|[[Category:Office Hours|{{{Resident}}}]]|{{ #ifeq:{{SUBPAGENAME}}|Teen Office Hours|[[Category:Teen Office Hours|{{{Resident}}}]]|}}}}|}}</includeonly><noinclude>
== Productivity ==
[[Template:Office Hours]], [[Template:Office Hours/include]] and [[Template:Office Hours/teen-include]] were created in order to improve productivity amongst Lindens & Residents who hold in-world office hours.

I noticed that Office Hours were being listed in multiple places ([[Office Hours]] and the Lindens' User-pages), and as any developer knows, duplication of data is bad.

[[User:SignpostMarv Martin|SignpostMarv Martin]] 04:39, 6 August 2007 (PDT)

== Setting up your Office Hours ==
See [[#Usage|usage]] for how to use the '''Office Hours''' template.

=== Main Grid ===
Create an article named '''Office Hours''' in your user space, e.g. [[User:Blue Linden/Office Hours]]

=== Teen Grid ===
Create an article named '''Teen Office Hours''' in your user space, e.g. [[User:Blue Linden/Teen Office Hours]]

== Displaying your Office Hours ==
=== Main Grid ===
<nowiki>{{Office Hours/include|First Last}}</nowiki>, e.g. <nowiki>{{Office Hours/include|Blue Linden}}</nowiki>

=== Teen Grid ===
<nowiki>{{Office Hours/teen-include|First Last}}</nowiki>, e.g. <nowiki>{{Office Hours/teen-include|Blue Linden}}</nowiki>

Place your link [[Office_Hours | here]], in the appropriate location.

== Usage ==
<nowiki>{{Office Hours
|Resident=SignpostMarv Martin
|location=nowhere in particular
|times=* no time in particular
|topics=*no topics in particular
|}}</nowiki>
{{:User:SignpostMarv Martin/Template:Office Hours
|Resident=SignpostMarv Martin
|location=nowhere in particular
|times=* no time in particular
|topics=*no topics in particular
|}}
[[Category:Office Hours|Office Hours]]
[[Category:Teen Office Hours|Teen Office Hours]]
</noinclude>

User:Q Linden/Office Hours

2007-09-24T13:32:55Z

Q Linden:

{{Office Hours |Resident=Q Linden |http://slurl.com/secondlife/Longfellow/200/136/34?title=Q%27s%20Land%20in%20Linden%20Village |times=* Mondays, 7:30-8:30 AM PDT |topics=* User experience, construction, architecture, open source, science fiction, cycling, games|location=[http://slurl.com/secondlife/Longfellow/220/168/25 Q's land] |}}

User:Q Linden/Office Hours

2007-09-21T02:13:01Z

Q Linden:

{{Office Hours |Resident=Q Linden |http://slurl.com/secondlife/Longfellow/200/136/34?title=Q%27s%20Land%20in%20Linden%20Village |times=* Mondays, 7:30-8:30 AM PDT |topics=* User experience, construction, architecture, open source, science fiction, cycling, games |}}

User:Q Linden/Office Hours

2007-09-21T02:09:07Z

Q Linden:

Here's my office hours:

{{Office Hours |Resident=Q Linden |http://slurl.com/secondlife/Longfellow/200/136/34?title=Q%27s%20Land%20in%20Linden%20Village |times=* Mondays, 7:30-8:30 AM PDT |topics=* User experience, construction, architecture, open source, science fiction, cycling, games |}}

User:Q Linden/Office Hours

2007-09-21T02:04:56Z

Q Linden: New page: Here's my office hours: {{Office Hours |Resident=Q Linden |http://slurl.com/secondlife/Longfellow/200/136/34?title=Q%27s%20Land%20in%20Linden%20Village |times=* Mondays, 7:30-8:30 AM PDT ...