[opensource-dev] [POLICY] Banning TPV not on the TPV list

[Altair Sythos Memo]

On Fri, 10 Sep 2010 10:50:01 -0400
"Oz Linden (Scott Lawrence)" <oz at lindenlab.com> wrote:


> >> >  You said "imho*ALL*  non TPV listed viewers should be
> >> > blacklisted...."
> 
> All viewers must comply with the Third Party Viewer Policy.
> 
> Viewers in the directory are ones that have certified that they are 
> compliant - viewers not in the directory may or may not be compliant, 
> but it's up to the user to determine that.
> 
> Using a non-compliant viewer or distributing one are both ToS
> violations.
> 
> None of this is really an opensource-dev topic, however.


i think is related to opensource too, a lot of "developers" don't know
the differences between an opensource viewer and a businness ToS, by
the way some "Linden" are here a lot of people believe server's
services provided by LL are "open" too. A missing information (or
missing people skill to RTFM and read ToS) can cause only damage to
OpenSource project like this.

People *MUST* understand this is an opensource project, sponsored by LL
but LLìs services (like the grid) are another pair of shoes.

A lot of developers here (or outside here) don't understand tossing a
patch here isn't "gift code to LL" but is "gift code to
community" (real meaning of opensource). 

My experiences in opensource projects sponsored by company with a own
businness is quite low, i've only worked on Familiar Linux 11-12years
ago (sponsored by COMPAQ, before COMPAQ sold handhelds division to HP).
Developement model and flow was simple but it work (not so far from
this one used here, just a bit more documented). I wish share it here,
maybe may be usefull to tuneup.

Is like a pyramid, on lower slice everybody with rights enabled 
can throw patches, rules to accept patches in this step are easy:
- no warning neither error
- other code don't be broken by a patch (if add feature A, and A work
but broke feature B isn't good)
- base guidelines matching (no features with negative behaviour, viewer
example may be copybot features)

Step after some skilled/old developers review each patch, and fit them
in a controlled way to check aftermath on global code, this step
generate a daily build for a initial check or compiled cource, where
few tester can diagnose what don't work and why) only after a
opensource QA check the patch if match sponsor/hoster requirements
[alpha stage]

If it compile, if no bad aftermath, if no other code reason, the patch
is checked by sponsor/hoster QA, if ok the patch will be slided on "beta
stage", where a wider spread of tester (less skilled, just to detect if
something don't work, with the requirement to diagnose why not work) to
let release run on a wider kind of operating system and hardware


last step before "Release" is like a "release candidate", where all
people, developers, tester and other test the code on a broad-spectrum
variety of OS, hardware, entwork conditions, field applications (busy
sim, lag).

if to last step all work patch drop in release code, witha  very low
requirement of handwork requirement by sponsor/hoster (in THIS case, LL
businness is provide grid and services, not do babysitting to
opensource viewer ;) )

and, obviously... a bug will be discovered after 2 minth of running
code as "release"

if now the workflow already is this ia sk excuse... but maybe better if
somebody add mroe details on wiki/else why not so clear and i believe a
lot of coder/developers/other_viewer_teams don't know/understand how
use all these tools provided with this project to create a better
viewer... especially top steps aren't clear...