Viewer Branch Changes

[Signal Linden (Bennett Goble)]

A couple more changes to keep things exciting:

The viewer's "master" branch will be renamed "main" to make it consistent with LL's internal repos and git's future defaults.

A new branch called "contribute" has been added to serve as a landing space for incoming PRs. This branch is similar to a develop branch in git flow, and will provide a consistent destination for external and some internal PR integration.

The contribute branch will be the default branch on GitHub so beware: it can contain unstable changes. If you want to track LL stable, please only pull from the main branch.

-Signal

[Henri Beauchamp]

Greetings,

Sorry if my question looks stupid, but this is new to me (I never used
LL's autobuild)...

How do you build a Windows SL viewer from a forked viewer repository
on github (so that, before pushing a PR, we can verify that a given
commit does not break the build) ?

I tried via github codespaces, but while I found various bits of info
on the Wiki to build under Windows, none match this case, since
codespaces are Linux VMs...

Henri.

[Signal Linden (Bennett Goble)]

Alright, I'm back from my remote yurt and can provide some unhelpful thoughts:

LL is planning on building the viewer using GitHub Actions in the coming months. Unfortunately, until then the process is the same as it was on BitBucket: the responsibility is foisted upon the submitter. My recommendation is to exercise a bit of due diligence based on how risky the changes are for other platforms. Low risk, platform agnostic change? Verify on your host OS and submit a PR. High risk, platform-specific change or change that might impact different platforms? You might want to provision a VM to test a build or something similar. As this somewhat well-known gist on PR etiquette states "It is not the reviewers responsibility to test the code."

Unfortunately, the absence of public-facing CI/CD makes the trivial task of evaluating build compatibility rather painful. So, while it is the reviewers responsibility to test, it is the maintainers responsibility to help make testing easy. I'm hopeful GH Actions will resolve this but don't have magic advice in the meantime. I've been trying to update build instructions on wiki.lindenlab.com, but there's always room for improvement.

As for using Codespaces: you may be breaking some new ground there. I'm not aware of anyone else having attempted to build the viewer using GH's hosted dev environments. I'm not sure it's possible considering what you acknowledge: these environments are linux only AFAIK.

-Signal

[Henri Beauchamp]

On Tue, 29 Nov 2022 12:21:02 -0800, Signal Linden (Bennett Goble) wrote:

> LL is planning on building the viewer using GitHub Actions in the
> coming months.

That would be great ! :-)

My "problem" is that the PRs I could make would come from the changes
I made to my own viewer, which has been forked from Snowglobe v1.5
over a decade ago and to which I backported code from LL's v2+ viewers
over years.
While there is a lot of common code in them, there are also many, many
differences (from small changes to full rewrites) with LL's code-base
as it is nowadays...

This means that large scope changes do require compiling LL's viewer
code to detect any glitch due to code variations.
For example, there is currently a thread safety issue in LL's code-base
dealing with LLImageGL and LLGLTexture which are using a non-thread-safe
ref-counting (LLRefCount instead of LLThreadSafeRefCount) while GL
images are now used in threads (with ref() and unref() calls). This is
a trivial change in appearance, but it requires checking that the code
still compiles (because LLThreadSafeRefCount is no-copy and those two
classes are the parents of all other viewer textures sub-classes).

If submitting PRs involves recompiling LL's viewer by myself, on my
system (while, sadly, LL's viewer won't even compile under Linux,
which is my development environment), this means also for me a lot
of time to devote to it, from creating a new VBox Windows VM with all
the necessary tools, learning how to build with LL's autobuild & Co,
re-packaging some "missing" viewer packages (e.g. FMOD, HAVOK stubs,
etc)...

I sadly I do not have free time to devote to this, so aside from small
scope changes (i.e. changes for which I am confident they won't break
anything elsewhere in LL's code), I'm afraid my PRs will stay rather
limited for now. :-/

Regards,

Henri.

PS: to other contributors reading this: feel free to experience the
LLThreadSafeRefCount changes by yourself and to push a verified
PR to fix that thread-safety issue...

[Monty Brandenberg]

On 11/29/2022 5:09 PM, Henri Beauchamp wrote:

> For example, there is currently a thread safety issue in LL's code-base
> dealing with LLImageGL and LLGLTexture which are using a non-thread-safe
> ref-counting (LLRefCount instead of LLThreadSafeRefCount) while GL
> images are now used in threads (with ref() and unref() calls).

:poop: