On Fri, 10 Sep 2010 10:50:01 -0400 "Oz Linden (Scott Lawrence)" <o...@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... _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
