Re: [opensource-dev] Blocking viewers.
The Emerald login screen is still under the control of the same people right now. These people are recently banned from SL and more than likely holding personal vendettas. Of course it needs to be blocked theres a genuine threat there. Maybe not in the main code of the viewer but definately on the login screen. If LL didn't act and something happened to people using Emerald the law suites would be heading the way of the real corporation with real money and a duty to protect it's customers. On , Harold Brown labrat...@gmail.com wrote: ANY Secondlife Viewer could be used for the exact same type of DDoS attack. Even more so the 2.0 viewers with Media on a Prim. The DDoS was from a webpage with hidden images being called from another site. Not from the clients being used as a Bot network. In this case it just happened to be the Viewer login screen. On Wed, Sep 8, 2010 at 6:09 PM, Maya Remblai snowfox...@dragonkeepcreations.com wrote: Oh for crying out loud...Emerald DID cause a DDoS attack, which is a CRIME. It also collected information about users that it shouldn't have. Those are facts that LL is aware of. It's a dangerous piece of software and has no right to connect to the grid now. I used to use Emerald, and not many people advocated it more than me, but now I won't touch it because I know it's dangerous. LL did the right thing, and I'm impressed that they had the guts to do it at all. There was nothing personal or political about it. I do hope that LL will learn from the drama though, and get their act together with viewer work in general. End of story. Go find another TPV and get on when your life. Most TPVs have the same feature set as Emerald now anyway, like temp uploads and useful radar. Maya ___ 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 ___ 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 ___ 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
Re: [opensource-dev] Blocking viewers.
The gist of this seeming to be that allowing a Third Party client the ability to use LLKDU.dll means that client is no longer TPV compliant. Interestingly enough, the Emergence viewer (published just before Phoenix) offers to install LLKDU.dll (i think it does so by downloading the official viewer and extracting the dll file), yet, is also listed in the TPVD : Emergence Viewer 7 Sep 2010 It did ask me while installing, the application directory indeed holds llkdu.dll, the release notes actually mention it: Changes from version 1.5.0.0 to 1.5.0.1 Dictionaries now downloaded dynamicly again Fixed bug in login page and in clothing protection (showing as emergence instead of emerald) *llkdu added to installer and now working in viewer* User agent refined Installer made red :D and smaller So, i'm at least confused about this EMKDU and LLKDU legal status, and even more why not only EMKDU as well as LLKDU was used as argument against Emerald, i.e. Emerald (before the blow up) was requested also not to use LLKDU. I quote Aradella Steadham: Linden Lab has made demands of the team that are impossible to meet. Among the demands not listed publicly elsewhere was to publicly release an RC without any ability to load the emkdu or llkdu files. This was do-able. The final demand was to 'delete' 3 key members of our team. While making this demand, Linden Lab was quite aware that this was effectively the guillotine to the project. Last not least, i think LL has acted pretty reasonable, identified the 3 brats in the Emerald team succesfully, also was very rapid in accepting BOTH Phoenix and Emergence in the TPVD. So rumours about 'viewer 2 only' and 'linden banning emerald because it is too succesful' seem to be plain wrong in my view. regards, and sorry for bothering with offtopic issues, TT 2010/9/9 Harold Brown labrat...@gmail.com In regards to Phoenix vs Emerald. The ONLY things Phoenix removed from the client that made them TPV compliant was the EMKDU.dll file (as well as removing the ability to use the LLKDU.dll) The gist of this seeming to be that allowing a Third Party client the ability to use LLKDU.dll means that client is no longer TPV compliant. Interesting enough the only valid arguement for the removal is the fact that KDU is a closed source binary and the client is GPL. That arguement is, of course, only valid for viewer code earlier than Snowstorm as the code license was changed to LGPL. Honestly with the impending removal of Snowglobe from the Linden Lab version control repositories, this all reeks of ways to force people to the new Viewer 2.x interface. One which I personally can not use for any extended lengths of time as it just doesn't flow naturally to me as a User Interface. On Wed, Sep 8, 2010 at 3:12 PM, Marc Adored m...@inworlddesigns.com wrote: I agree and Phoenix seems to be coming only very well to and all the negativity behind emerald seems to be gone in the atmosphere of phoenix. I am pretty excited to see where it heads! Maybe this thread can be saved and put back on topic :D Tom I know your upset about them banning Emerald but it was in their right to do so there is no arguing that. I suggest that if you like emerald you should try phoenix it is the cleaned up spawn of emerald and has all the non-controversial developers from emerald working on it even LGG :D I am sure you will notices differences in the viewer but it has all the same features plus some really neat new ones. On-topic part is phoenix is shaping up to be a pretty decently organized opensource viewer should we focus on that now? :D On Wed, Sep 8, 2010 at 6:04 PM, Altair Sythos syt...@gmail.com wrote: On Wed, 8 Sep 2010 17:59:41 -0400 Marc Adored m...@inworlddesigns.com wrote: Emerald is a perfect example of that. Everyone is upset and mad at linden for banning Emerald but no body cared what the developers of Emerald were doing before it effected them directly. I wont go into a flame war over one of my favorite viewers but I just wanted to make that point. Emerald have good reason to be blacklisted, there is the next step called phoenix, cleaned by bad code and bad elements, all other is only a lil actors show... ___ 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 ___ 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 ___ 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
Re: [opensource-dev] Blocking viewers.
On Thu, Sep 09, 2010 at 12:02:46AM +0200, Altair Sythos Memo wrote: imho *ALL* non TPV listed viewers should be blacklisted is safer, for both resident and developers It's also safer to put all humans in a straight jacket, that would also probaly solve most current enviroment problems. The downside does however still make most realise the down sides of this is way bigger that the gains. Most TPV's contains fixes that make them safer that the LL viewer, Linden have so far had a to slow acceptance of user fixes.Or for some reason not let them in. The new Snowstorm hopefulle helps this. There are still however much smell in the code, not more and in someplaces less that most big projects. But it's there all projects get them. And why the heck did i get my self involved again... I need my non coding time... / Balp -- o_ Anders Arnholm, o/ /\and...@arnholm.se /|_, \\http://anders.arnholm.se/ / ` -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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
Re: [opensource-dev] Incomming group/im Toasts
This looks good to me and very easily implemented. I have only one suggestion though if someone is using multiple accounts on a system it might be best to move the settings to steeing_per_account.xml. Me personaly I would be using this setting as im currently using a 'tweek' that kills those toasts and this would be a better option. -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Alexandrea Fride Sent: Thursday, September 09, 2010 7:35 AM To: opensource-dev@lists.secondlife.com Subject: [opensource-dev] Incomming group/im Toasts As a user i would like to disable incoming group/im toasts from showing up in viewer 2, especially if a user is in busy groups this can be pretty annoyingly i made a jira http://jira.secondlife.com/browse/VWR-22915 and included a patch that easly can do it the path isent big so it could be done easly (or modifyd to use LL coding standards if someone whants to check that patch) Greetings Alexandrea Fride ___ 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3123 - Release Date: 09/08/10 13:41:00 ___ 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
Re: [opensource-dev] Compiler optimizations on Viewer and LLKDU
Sheet Spotter wrote: 1. Are there any plans to enable higher levels of compiler optimizations for the viewer? Yup! There are a wad of changes like this in the dev pipeline, but we want to prove the heck out of them (they are still considered experimental and somewhat intertwined with some other, even-more-experimental changes). 2. Also, would the LLKDU library benefit from higher levels of compiler optimizations? Probably not the version we're using right now. Cheers, -tofu ___ 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
Re: [opensource-dev] Blocking viewers.
This is not a bad idea at all, except that LL is here for the money so they will refuse it. But opensim might use the idea. You just have to adjust a bit ;). Instead of having people pay for a server 24/7, you could allow them to pay for a certain period of the day (many would find 2 hours per day enough). Then the same machine that would host their sim could be used for other sims during the other 22 hours. I'm sure that with that method it should be possible to cut the price of sims to 25%. But then again, Linden Lab is about to screw us all already in this regard by going to limit the resources of every (private) sim to the tiny share that one would have when the sim is fully loaded. So, that means that you can only use those resources that otherwise would have been available if the sim was loaded to the max 24/7 (which is clearly isn't the case on 99.9% of the sims). As a direct result the same hardware can be used for more sims at the same time while you still pay the same (using virtual hosting). The price SHOULD be cut to 10%, so in effect it's the same idea, but now with all financial benefit exclusively for LL. On Thu, Sep 09, 2010 at 09:28:06AM -0400, malachi wrote: or we could do what that one episode of the outer limits called stasis where they take and split the population of the world into 3 groups. alphas betas and elites. then every 72 hours the alphas and betas switch on a cryogenic freeze. half the population sleep while the other half run about working and what not. and the elite stay away all the time. Lindens are the elite i suppose. now if we can just get the system to let only half of the people log in for 3 days. and the other half stay offline. and alternate. we would experience much less lag i think lol -- Carlo Wood ca...@alinoe.com ___ 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
[opensource-dev] This cannot be right...
When I start V2 Dev 209046, this show up in my system.log. It goes on producing more than 500 entries per second. Sep 9 12:44:49 iMac ntpd[29]: time reset -0.415501 s Sep 9 12:48:24 iMac [0x0-0x3b23b2].com.secondlife.indra.viewer[12501]: libndofdev: initializing... Sep 9 12:48:24 iMac [0x0-0x3b23b2].com.secondlife.indra.viewer[12501]: libndofdev: starting runloop... Sep 9 12:48:24 iMac [0x0-0x3b23b2].com.secondlife.indra.viewer[12501]: libndofdev: using valid HID device: Sep 9 12:48:24 iMac [0x0-0x3b23b2].com.secondlife.indra.viewer[12501]: libndofdev: manufacturer=Primax Electronics; product=Apple Optical USB Mouse; axes_count=5; btn_count=4; min=-3000; max=3000; absolute=1; valid=1; private_data=0x1d767840; Sep 9 12:48:24 iMac [0x0-0x3b23b2].com.secondlife.indra.viewer[12501]: curr_loc_id=FD113000 Sep 9 12:48:24 iMac [0x0-0x3b23b2].com.secondlife.indra.viewer[12501]: scales: [23.622047 23.622047 Sep 9 12:48:24 iMac [0x0-0x3b23b2].com.secondlife.indra.viewer[12501]: 23.622047 23.622047 23.622047 0.00 ] Sep 9 12:48:24 iMac [0x0-0x3b23b2].com.secondlife.indra.viewer[12501]: offsets: [0.00 0.00 0.00 0.00 0.00 0.00 ] Sep 9 12:49:43 iMac /Applications/Second Life Development.app/Contents/MacOS/Second Life[12501]: dnssd_clientstub deliver_request: socketpair failed 24 (Too many open files) Sep 9 12:49:43: --- last message repeated 499 times --- Sep 9 12:49:43 iMac /Applications/Second Life Development.app/Contents/MacOS/Second Life[12501]: *** process 12501 exceeded 500 log message per second limit - remaining messages this second discarded *** Sep 9 12:49:43 iMac /Applications/Second Life Development.app/Contents/MacOS/Second Life[12501]: dnssd_clientstub deliver_request: socketpair failed 24 (Too many open files) Sep 9 12:49:44: --- last message repeated 499 times --- Sep 9 12:49:44 iMac /Applications/Second Life Development.app/Contents/MacOS/Second Life[12501]: *** process 12501 exceeded 500 log message per second limit - remaining messages this second discarded *** Sep 9 12:49:45 iMac /Applications/Second Life Development.app/Contents/MacOS/Second Life[12501]: dnssd_clientstub deliver_request: socketpair failed 24 (Too many open files) Sep 9 12:49:45: --- last message repeated 499 times --- Sep 9 12:49:45 iMac /Applications/Second Life Development.app/Contents/MacOS/Second Life[12501]: *** process 12501 exceeded 500 log message per second limit - remaining messages this second discarded *** Sep 9 12:49:45 iMac /Applications/Second Life Development.app/Contents/MacOS/Second Life[12501]: dnssd_clientstub deliver_request: socketpair failed 24 (Too many open files) ___ 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
Re: [opensource-dev] Compiler optimizations on Viewer and LLKDU
On Thu, 09 Sep 2010 13:48:23 +0100 Tofu Linden t...@lindenlab.com wrote: Sheet Spotter wrote: 1. Are there any plans to enable higher levels of compiler optimizations for the viewer? Yup! There are a wad of changes like this in the dev pipeline, but we want to prove the heck out of them (they are still considered experimental and somewhat intertwined with some other, even-more-experimental changes). maybe is the right time to check libs versions... GTK are old enough and already both no cygwin, *nix and macosX newer ones (with more performances on mixed thread, where mixed thread appliable like dual core processor +HT than report to OS 4 cores, a real core have a different cache code managing of a virtual core like on a HT), GCC4 is s old, more and big improvement made since 4.1, more again on 4.2 (and maybe setup makefile to create target as i686, not anymore i386, to allow GCC enable advanced features, no less than i686 is required to run a viewer) ___ 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
Re: [opensource-dev] Blocking viewers.
Its an illusion OpenSim is cheaper if you look at total cost of ownership and include all time related to managing it. Seems this is the wrong mailing list for this. Please take it to the forums or your blog. M. -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Carlo Wood Sent: Thursday, September 09, 2010 12:53 PM To: malachi Cc: opensource-dev@lists.secondlife.com; Anders Arnholm Subject: Re: [opensource-dev] Blocking viewers. This is not a bad idea at all, except that LL is here for the money so they will refuse it. But opensim might use the idea. You just have to adjust a bit ;). Instead of having people pay for a server 24/7, you could allow them to pay for a certain period of the day (many would find 2 hours per day enough). Then the same machine that would host their sim could be used for other sims during the other 22 hours. I'm sure that with that method it should be possible to cut the price of sims to 25%. But then again, Linden Lab is about to screw us all already in this regard by going to limit the resources of every (private) sim to the tiny share that one would have when the sim is fully loaded. So, that means that you can only use those resources that otherwise would have been available if the sim was loaded to the max 24/7 (which is clearly isn't the case on 99.9% of the sims). As a direct result the same hardware can be used for more sims at the same time while you still pay the same (using virtual hosting). The price SHOULD be cut to 10%, so in effect it's the same idea, but now with all financial benefit exclusively for LL. On Thu, Sep 09, 2010 at 09:28:06AM -0400, malachi wrote: or we could do what that one episode of the outer limits called stasis where they take and split the population of the world into 3 groups. alphas betas and elites. then every 72 hours the alphas and betas switch on a cryogenic freeze. half the population sleep while the other half run about working and what not. and the elite stay away all the time. Lindens are the elite i suppose. now if we can just get the system to let only half of the people log in for 3 days. and the other half stay offline. and alternate. we would experience much less lag i think lol -- Carlo Wood ca...@alinoe.com ___ 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 ___ 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
Re: [opensource-dev] This cannot be right...
On Thu, 9 Sep 2010 15:47:22 -0400 Ponzu lee.po...@gmail.com wrote: Tried the later build, 209229. Same line in syslog.log Sep 9 14:02:52 iMac [0x0-0x3df3df].com.secondlife.indra.viewer[12783]: libndofdev: [cut] ehm... in advanced/develop menu do you have enabled debug for GL and pipeline? :) ___ 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
Re: [opensource-dev] This cannot be right...
On 9/9/2010 3:47 PM, Ponzu wrote: Tried the later build, 209229. Same line in syslog.log A lot of completely unrelated programs are reporting the deliver_request: socketpair failed 24 (Too many open files) error (winbindd, hg, omd, Brother printers). Suggest you try two things: 1. Use 'lsof -p pid' while this occurs to see what is consuming all the file descriptors. Some additional options might be needed to get deeper information. 2. Bump the limit up in a process (ulimit -n 1024) and then use 'open' to start the viewer in that process and see if that works around the limit. I don't know what the real issue is but the internetz are full of *interesting* theories. Bonjour seems to be the likely candidate: http://discussions.apple.com/thread.jspa?threadID=2186838start=30tstart=0 http://discussions.apple.com/thread.jspa?messageID=10121652#10121652 http://discussions.apple.com/thread.jspa?threadID=2139587tstart=0 http://developer.apple.com/library/mac/#qa/qa2001/qa1297.html m -- Monty Brandenberg mo...@lindenlab.com ___ 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
Re: [opensource-dev] Compiler optimizations on Viewer and LLKDU
KDU automatically detects and uses cpu optimization if its available. The only compiler options I'm aware of are those that enable or disable threading of decoding, which I suspect won't be of much benefit for the type of images uses in SL(small and fast to decode). Compiling the base code with optimizations for CPU instruction sets(SSE,etc) might help slightly, but the results would be minimal. In the long ago days of Emerald, compiler optimizations were evil, and caused obscure bugs that were hard to find, most of them would show up on linux and mac, but there were some on windows too, related to using SSE2 instruction sets that would cause the builds to crash at random. At the time, I think LL has managed to balance optimization flags with stability, It might be wise to leave what is known to work alone, save there is enough manpower and time to extensively test the use of new instruction sets across a great number of machine setups. In the testing that was done internally for Emerald, results were rather surprising, using SSE2 either causing a major slowdown and choppy behavior for the client on some setups, or the results were between 3 and 8% frame rate increase for a test scene. The major improvement that I remember was in avatar rendering time, as well the rebuilding of face geometry, where it could take advantage of doing multiple things at once. None of the testing done was terribly organized or reliable though, so I hope somebody else can set up some tests and compare this a bit more accurately. Summary: Might want to leave this as is, for stability, because the gains are either negative, or small enough that its not worth the possible losses. ___ 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
[opensource-dev] Snowstorm Daily Scrum Summary - 09/09/2010
Date: Thu Sep 9, 2010 Also available here: https://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive *=== General Notes ===* * Don't forget to grab tasks from the Sprint Backlog and update your time remaining on that task each day! * Merge Monkey of the Day: Merov *===Team Status===* *Aimee Linden* *PAST* OOO *Tofu Linden* *PAST* * DEV-30773 llTextBox() * Some Coverity bug fixes * SNOW-606 juggling (and ultimate backout) * Some OOO *FUTURE* * DEV-30773 llTextBox() * Make myself a teamcity task for staging * Some OOO *IMPEDIMENTS* * Linux build machine needs a bit of system-image love - little fuzzy on who owns that, pinged CG and Sabin. *Oz Linden* OOO *Merov Linden* *PAST* * VWR-22761 : LLKDU upgrade: Perf tracking ** Got a KDU baseline and compared with OpenJpeg. First data show that OpenJpeg 4 times slower in decompression than KDU. ** Posted a doc: https://wiki.secondlife.com/wiki/Performance_Testers ** First commit to dev repo : https://bitbucket.org/merov_linden/viewer-development-vwr-22761/changeset/71b1676532b3 * VWR-22759 : Chat Translator: Got green from Esbee and Q on Design Review *FUTURE* * VWR-22761 : LLKDU upgrade: Polish doc, get more baseline data * VWR-22759 : Chat Translator: Move to next stage *IMPEDIMENTS* * Kakadu license upgrade *Q Linden* *OOO* *Esbee Linden* *PAST* * Worked on draft of Jira VWR workflow proposal and discuss w/Q * Moved Snowstorm Team Backlog to GH * Trying out new Jira VWR workflows *FUTURE* * Schedule meeting with Orange, Gentle, and LordGregGreg for next week. * Share UI customization notes and sketches with Rhett from XD team * Finish draft of Jira VWR workflow proposal * Set up sprints in GH *IMPEDIMENTS* * Not receiving Tofu's email to mailing list (still not sure why) *Paul ProductEngine* *PAST* * VWR-22346 (Appearance 'Wearing' tab: Add Take off / Detach function to the gear menu) **Corrected according to Vadim's commentaries *FUTURE* * VWR-22169 (Delete outfit confirmation message doesn'r appear if use context or gear menu on 'My Outfits' tab) estimate ~ 8 hours *IMPEDIMENTS* *none *Andrew ProductEngine* *PAST* *Bug VWR-22008 (People you called via Adhoc are not shown in Recent tab). **Discussed with Andrey, didn't find solution. Will ask in jira when able to add watchers * Major bug VWR-22125 (Mini-inspector floater doesn't appear after click on 'i' icon in IM or Nearby chat window). **Found problem. Took more time due to additional bug (VWR-22898 - Some buttons disappear when clicked) **Fixed, will apply fix when Richard fixes VWR-22898 (Vadim linked them) * Bug VWR-22888 (Empty space appears in the top of Home side panel after redocking) **WIP. Estimate - 6h *FUTURE* *VWR-22888 (Empty space appears in the top of Home side panel after redocking) *IMPEDIMENTS* * none *Vadim ProductEngine* *PAST* * sent email to viewer-tech about problems building on Ubuntu 10.04, Tofu immediately merged the fix. ** later it turned out fix broke the build on LL servers, fix has been rolled back, discussion continues (?) * Filed a ticket (VWR-22898) regarding disappearing buttons problem. *Bug VWR-22891 (Docked IM window hides when try to share an item while My Inventory SP is undocked): **Fixed * Bug VWR-22896 (Panel state resets on dock/undock): **Fixed but want to test some more to prevent accidental regressions *FUTURE* *Paul's review request *Finish VWR-22896 *Other bugs *IMPEDIMENTS* * None *Seth ProductEngine (Sergey)* OOO - Vacation *Andrey ProductEngine* *PAST* * filed issues discovered yesterday during smoke test and VWR-20694 testing * started revision of existing TPE regression suite for viewer *FUTURE* * complete revision and identify gaps (Home, Picks/Classifieds, My Profile have no formal regression cases at least) * add sidetray panel docking/undocking test cases *IMPEDIMENTS* * none *Grumpity ProductEngine (Anya)* *PAST* *played with new jira *workflow followup *server testing followup *FUTURE* *detachable sidebar bottom bar review *transition issues from VWR to STORM? *update sprint backlog *IMPEDIMENTS* *cannot transition issues from VWR to STORM ___ 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
[opensource-dev] Snowstorm clarification
Maybe I missed something when Snowstorm was announced, but I was under the impression that LL was going to be more open about viewer development. Before Snowstorm there were code drops into viewer-external on SVN several times a week (or weekly at worst). Since Snowstorm there haven't been any noteworthy upstream code drops from LL into viewer-development (2.1.1 was added, but then it was already on SVN before) that aren't resident contributions or reintegrating Snowglobe patches. If development of the viewer hasn't been halted for the past three weeks, where is all of the code going? *confuzzled* Or in the new terminology: as a resident, I would like to know why an open development announcement has the net effect of LL releasing less than it did prior to that announcement. Kitty ___ 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
Re: [opensource-dev] Snowstorm clarification
I think the Lindens have pretty much left Subversion alone since they stopped pushing out code specially made for the public. They've switched to Mercurial, and the repository they're using at http://hg.secondlife.com/viewer-development seems to have a fair amount of activity... On Thu, Sep 9, 2010 at 7:30 PM, Kitty sl...@catznip.com wrote: Maybe I missed something when Snowstorm was announced, but I was under the impression that LL was going to be more open about viewer development. Before Snowstorm there were code drops into viewer-external on SVN several times a week (or weekly at worst). Since Snowstorm there haven't been any noteworthy upstream code drops from LL into viewer-development (2.1.1 was added, but then it was already on SVN before) that aren't resident contributions or reintegrating Snowglobe patches. If development of the viewer hasn't been halted for the past three weeks, where is all of the code going? *confuzzled* Or in the new terminology: as a resident, I would like to know why an open development announcement has the net effect of LL releasing less than it did prior to that announcement. Kitty ___ 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 ___ 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
