[opensource-dev] [POLICY] Banning TPV not on the TPV list
Altair Sythos Memo
sythos at gmail.com
Sun Sep 12 07:54:07 PDT 2010
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
> 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
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
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...
More information about the opensource-dev