Re: [opensource-dev] Wiki posting: Open Source Repository Strategy
For a first shot it looks fine. I hope thou in the furture snow-glow will hang in hg directly from the viewer-public the. Svn branches between will only make extra work not really needed. But no need to stress that extra work. A project like snowglow is the most gaining on a distributed cm system. Skickat från min iPhone 22 mar 2010 kl. 04.38 skrev "Kent Quirk (Q Linden)" : > Hi, all. I've created a draft of our repository strategy for how we > will be handling open development branches at LL, and posted an > annotated diagram on the wiki. > >https://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy > > Questions and constructive commentary are encouraged. Since it's > policy we intend to follow, please edit only for clarity. If it > needs substantive tweaking, please let us do it. > > Thanks, > >Q > ___ > 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 > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- 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
[opensource-dev] food for (funny) thoughts...
Just saw an announcement for ubuntu 10.04... is it just me or does the colorscheme of SL 2.0 really fit into 10.04's default desktop color scheme like a foot in a sock? http://is.gd/aSANa *grin* LC ___ 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] Third party viewer policy: commencement date
I'd like to see this question answered, too. On Sun, Mar 21, 2010 at 06:08:58PM +0200, Ryan McDougall wrote: > The policy deeply confuses users and developers together, making it > appear to me that "users" can place "developers" in violation of your > policy against their will. > > Let me explain: > > Let's say I develop a client expressly designed to log into OpenSim > for example. Because of protocol compatibility, this client is > incidentally capable of logging into SL. If a user decides to to just > that, he is *clearly* a "User of Third Party Viewer". However, has he > just made me a "Developer of Third Party Viewer"? I see no language > that protects me from your policy. > > I've no interest in using LL's servers or enabling LL's business > model. I don't want to agree to the TVP. Has OpenSim's historical > choice of protocol placed it under LL's legal domain? If not, what > section of your policy protects me? > > Sincerely, > Ryan -- Carlo Wood ___ 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] Third party viewer policy: commencement date
Am Sonntag, 21. März 2010 18:24:13 schrieb Kent Quirk (Q Linden): > If you have legal questions about the implication of > documents, you should ask a lawyer, not a mailing list. the free software foundation has been notified. expect comms from their lawyers in the near future. ___ 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] Third party viewer policy: commencement date
Am Montag, 22. März 2010 12:44:57 schrieb Carlo Wood: > I'd like to see this question answered, too. > > On Sun, Mar 21, 2010 at 06:08:58PM +0200, Ryan McDougall wrote: > > The policy deeply confuses users and developers together, making it > > appear to me that "users" can place "developers" in violation of your > > policy against their will. > > > > Let me explain: > > > > Let's say I develop a client expressly designed to log into OpenSim > > for example. Because of protocol compatibility, this client is > > incidentally capable of logging into SL. If a user decides to to just > > that, he is *clearly* a "User of Third Party Viewer". However, has he > > just made me a "Developer of Third Party Viewer"? I see no language > > that protects me from your policy. > > > > I've no interest in using LL's servers or enabling LL's business > > model. I don't want to agree to the TVP. Has OpenSim's historical > > choice of protocol placed it under LL's legal domain? If not, what > > section of your policy protects me? > > > > Sincerely, > > Ryan Let's face it. Q has basically put a final answer to all our questions. how did he put it... "Similarly, any comment by one of Linden's lawyers in this forum or any other could possibly be treated as legally binding. That also goes for Linden employees, especially those with any seniority. So you're unlikely to get further remarks or "clarifications", except general statements that don't address specific questions. The policy was revised based on comments on this list and elsewhere. That's probably a pretty good indication that Linden Lab's lawyers now think it's clear enough to state its intent and to stand up in court if they need it to." therefor I notified the FSF of this stuff. Let's see what they think. ___ 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] Moving forward with open development
On Sun, Mar 21, 2010 at 10:41 PM, Dzonatas Sol wrote: > Ambroff Linden wrote: > > I don't know if this is true or not, but regardless, copyright > > assignment helps Linden enforce the GPL, which is good for everyone. > > That's why the FSF was also used as an example. > > > > -Ambroff > That is the ONLY reason that I didn't think about it too long, since I know that the FSF requires a signature for copyright assignment too, IN ORDER TO enforce the GPL in court (since only the copyright holder can do that). It would be totally not-done to then take my code and release it under a non-GPL license, most specifically, to release binaries without the ability for users to get the source code. That is why I got so upset when it was in the air if the official viewer would be closed again. I'm glad that this is clear now and that those parts that can legally be designed in the open are going to be, even. > Yes, a simple copyright assignment would be easier then a Contributor > Agreement: > > 1) Programmer A submits a patch under GPL to the GPL source. > 2) Programmer A makes sure patch is copyrighted by LL (copyright > assignment done). > You need to physically sign something to make that legally binding, I think (at least that is what the FSF says). > 3) LL applies patch and continues to distribute as usual by GPL. > Well... they also want to be able to take it back into their mainviewer, which for some reason seems to need to link with or use proprietary code, and therefore can't be released under the GPL. This being legacy from before making the viewer (partly) GPL is morally acceptable, as long as every time as much as possible is made open again. If possible, we should get rid of all this proprietary code however (for example, there is absolutely no reason to use libfmod anymore). Aleric ___ 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] Third party viewer policy: commencement date
Although the text of the TPV policy doesn't mention this, to protect developers who don't want their viewer to be subject to the unnamed penalties of said policy, Joe himself has said the following: "[The TPV policy] only governs viewers that actually do connect to the SL grid, not those that are capable of doing so (but don't.)" I'm not sure how reassured I should be. The thing I don't get is why LL gets to use all these fancy legalisms to protect themselves, but when we get nervous about it, they reply "hey, don't be suspicious -- assume we mean well!" Sorry but when you play the legalism game, drawing lines in the sand, saying "we have to protect ourselves" -- it cuts both ways. This should have been a consultation process to begin with, not a big ol' lawyering up, then push it out the door effective Apr 30th. Cheers, On Mon, Mar 22, 2010 at 1:44 PM, Carlo Wood wrote: > I'd like to see this question answered, too. > > On Sun, Mar 21, 2010 at 06:08:58PM +0200, Ryan McDougall wrote: >> The policy deeply confuses users and developers together, making it >> appear to me that "users" can place "developers" in violation of your >> policy against their will. >> >> Let me explain: >> >> Let's say I develop a client expressly designed to log into OpenSim >> for example. Because of protocol compatibility, this client is >> incidentally capable of logging into SL. If a user decides to to just >> that, he is *clearly* a "User of Third Party Viewer". However, has he >> just made me a "Developer of Third Party Viewer"? I see no language >> that protects me from your policy. >> >> I've no interest in using LL's servers or enabling LL's business >> model. I don't want to agree to the TVP. Has OpenSim's historical >> choice of protocol placed it under LL's legal domain? If not, what >> section of your policy protects me? >> >> Sincerely, >> Ryan > > -- > Carlo Wood > ___ 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] Wiki posting: Open Source Repository Strategy
*confused* I thought that we were going to use hg, so that commits made internally can be easilly and frequently pushed to a public repository. Is that "viewer-public"? Then why is there is there still a "viewer-external" using SVN? That kinda defeats the purpose of hg? I thought, and think, that snowglobe development should also be done with hg, so we can have all the benefits of having local repositories and experimental branches to developer and test patches. On Mon, Mar 22, 2010 at 4:38 AM, Kent Quirk (Q Linden) wrote: > Hi, all. I've created a draft of our repository strategy for how we will be > handling open development branches at LL, and posted an annotated diagram on > the wiki. > >https://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy > > Questions and constructive commentary are encouraged. Since it's policy we > intend to follow, please edit only for clarity. If it needs substantive > tweaking, please let us do it. > > Thanks, > >Q > ___ > 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] Moving forward with open development
Aleric Inglewood wrote: > It would be totally not-done to then take my code and release it under > a non-GPL license, most specifically, to release binaries without the > ability for users to get the source code. That is why I got so upset To be clear, Linden Lab does still plan to do this. There will be no GPL-satisfying code release for the "official viewer". What they are saying is that they are going to minimize the amount that the official viewer diverges. Howard, does LL still want to do things like OnRez where our code is licensed to third parties for completely closed forks? -Jason ___ 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] Third party viewer policy: commencement date
You too eh? See my correspondence with RMS that I forwarded to the list a while back On Mon, Mar 22, 2010 at 11:52 AM, Lance Corrimal wrote: > Am Sonntag, 21. März 2010 18:24:13 schrieb Kent Quirk (Q Linden): > >> If you have legal questions about the implication of >> documents, you should ask a lawyer, not a mailing list. > > the free software foundation has been notified. > > expect comms from their lawyers in the near future. > > ___ > 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 > -- “Lanie, I’m going to print more printers. Lots more printers. One for everyone. That’s worth going to jail for. That’s worth anything.” - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ 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] Third party viewer policy: commencement date
https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000521.html On Mon, Mar 22, 2010 at 1:02 PM, Gareth Nelson wrote: > You too eh? > See my correspondence with RMS that I forwarded to the list a while back > > On Mon, Mar 22, 2010 at 11:52 AM, Lance Corrimal > wrote: >> Am Sonntag, 21. März 2010 18:24:13 schrieb Kent Quirk (Q Linden): >> >>> If you have legal questions about the implication of >>> documents, you should ask a lawyer, not a mailing list. >> >> the free software foundation has been notified. >> >> expect comms from their lawyers in the near future. >> >> ___ >> 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 >> > > > > -- > “Lanie, I’m going to print more printers. Lots more printers. One for > everyone. That’s worth going to jail for. That’s worth anything.” - > Printcrime by Cory Doctrow > > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > -- “Lanie, I’m going to print more printers. Lots more printers. One for everyone. That’s worth going to jail for. That’s worth anything.” - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ 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] Wiki posting: Open Source Repository Strategy
Hi Q thanks for illustrating the planned process. On 03/22/2010 04:38 AM, Kent Quirk (Q Linden) wrote: > Since it's policy we intend to follow, please edit only for clarity. If it > needs substantive tweaking, please let us do it. > As not everyone who might find that wiki article will be reading this mailing list, you might want to enable stable versioning on it. That will still allow everyone to easily edit the "draft" version while you can review changes before you "verify" them and they go live as the "stable page". The Documentation Team uses that for the KB part of the wiki, so Torley etc. can probably tell you how to do it. > Questions and constructive commentary are encouraged. > * about *K)*-*N)*: In cases where none of planned new features require secrecy, can viewer-release be exported to a corresponding external branch, too? * about *M)*: Also in cases where none of planned new features require secrecy, can private beta be skipped in favor of an earlier public beta? * about *O)*: What about the inverse, can the community opt not to merge certain features from upstream (viewer-external) into Snowglobe? cheers Boroondas ___ 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] Wiki posting: Open Source Repository Strategy
On Mar 22, 2010, at 9:11 AM, Boroondas Gupte wrote: > Hi Q > > thanks for illustrating the planned process. > > On 03/22/2010 04:38 AM, Kent Quirk (Q Linden) wrote: >> >> Since it's policy we intend to follow, please edit only for clarity. If it >> needs substantive tweaking, please let us do it. >> > As not everyone who might find that wiki article will be reading this mailing > list, you might want to enable stable versioning on it. That will still allow > everyone to easily edit the "draft" version while you can review changes > before you "verify" them and they go live as the "stable page". The > Documentation Team uses that for the KB part of the wiki, so Torley etc. can > probably tell you how to do it. > Thanks, I'll look into that. >> Questions and constructive commentary are encouraged. >> > about K)-N): In cases where none of planned new features require secrecy, can > viewer-release be exported to a corresponding external branch, too? > about M): Also in cases where none of planned new features require secrecy, > can private beta be skipped in favor of an earlier public beta? I imagine that we'll have more external branches than are shown there. The idea is to publish as soon as we can reasonably do so, so I think that will have the effect you're looking for. > about O): What about the inverse, can the community opt not to merge certain > features from upstream (viewer-external) into Snowglobe? The merge to Snowglobe isn't automatic -- it probably requires intelligent merging. So if that includes leaving things out, so be it. The right way to do it will probably be to undo the changesets so that it doesn't become a fork that requires constant maintenance. ___ 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] Wiki posting: Open Source Repository Strategy
At this point, our internal branches still contain proprietary libraries and parts of our server code. We have to have an explicit export process to block that. We have a team working on "source code splitup" to finish the separation of our systems into libraries, and when that's finished I believe we'll be able to do it all with hg. On Mar 22, 2010, at 8:11 AM, Aleric Inglewood wrote: > *confused* I thought that we were going to use hg, so that > commits made internally can be easilly and frequently > pushed to a public repository. Is that "viewer-public"? > > Then why is there is there still a "viewer-external" > using SVN? That kinda defeats the purpose of hg? > > I thought, and think, that snowglobe development > should also be done with hg, so we can have all > the benefits of having local repositories and > experimental branches to developer and test patches. > > > On Mon, Mar 22, 2010 at 4:38 AM, Kent Quirk (Q Linden) > wrote: > Hi, all. I've created a draft of our repository strategy for how we will be > handling open development branches at LL, and posted an annotated diagram on > the wiki. > >https://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy > > Questions and constructive commentary are encouraged. Since it's policy we > intend to follow, please edit only for clarity. If it needs substantive > tweaking, please let us do it. > > Thanks, > >Q > ___ > 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] Wiki posting: Open Source Repository Strategy
On Mar 22, 2010, at 12:58 AM, Latif Khalifa wrote: > On Mon, Mar 22, 2010 at 4:38 AM, Kent Quirk (Q Linden) > wrote: >> Hi, all. I've created a draft of our repository strategy for how we will be >> handling open development branches at LL, and posted an annotated diagram on >> the wiki. >> >>https://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy >> >> Questions and constructive commentary are encouraged. Since it's policy we >> intend to follow, please edit only for clarity. If it needs substantive >> tweaking, please let us do it. > > Hello Q, > > It would help me better understand this process if I put some version > numbers on it (as of this moment). viewer-public branch is the > current 2.0 viewer, viewer-release (if it exists atm) would be 2.1 and > viewer-private features that are going to be added in 2.2 and beyond. > Please correct me if my understanding is correct. > Well, this process isn't all in place at this point. We'll finish setting it up once we've shipped Viewer 2 as the official release. But assuming we've gotten to that point, then viewer-public will contain some 2.1 work, and viewer-private will also contain some 2.1 work. When we're close to releasing 2.1, we'll merge to private and create the release branch. At that point, the private branch becomes 2.2 and 2.1 development is finished on release. > Also, I think that we would need more than a single viewer-external > branch in the public svn. There should probably be branching of > viewer-external to viewer_2_0 just before we export viewer-public to > viewer-external at the point M on the diagram. You're right -- this diagram is a bit limited. I'm certain we'll have multiple branches, and we should have a place where someone can go to get the definitive source for any given release. Thanks. Q ___ 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] food for (funny) thoughts...
You're damn right it does! I just installed the LTS Beta 1 on my system yesterday. Had a few quirks, but other than that it worked fine. Not much difference between Karmic, but I suspect more to come in Beta 2, RC, and Final. Jonathan Irvin Cell: +1-318-426-5253 Email: djfoxys...@gmail.com On Mon, Mar 22, 2010 at 03:20, Lance Corrimal wrote: > Just saw an announcement for ubuntu 10.04... > > is it just me or does the colorscheme of SL 2.0 really fit into 10.04's > default desktop color scheme like a foot in a sock? > > http://is.gd/aSANa > > > *grin* > > > LC > ___ > 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] Wiki posting: Open Source Repository Strategy
On Mon, Mar 22, 2010 at 1:59 PM, Kent Quirk (Q Linden) wrote: > The merge to Snowglobe isn't automatic -- it probably requires intelligent > merging. So if that includes leaving things out, so be it. The right way to > do it will probably be to undo the changesets so that it doesn't become a > fork that requires constant maintenance. Merov specificaly talked about this point at last Thursdays snowglobe meeting. Although we were running short of time and there may be need for some fine details. The consensus of those present was to manually merge from vendor branch about once a week. A manual merge is probably vital here as snowglobe will be adding its own features and fixes and any of these could be damaged by incomming code based of a slightly different code base. Hopefully a great deal of snowglobe patches will make there way back to the main viewer code anyway and this type of conflict will not happen too often. The other thing Merov said is if a vendor imported patch breaks/conflicts with snowglobe then just revert that patch and flag up the situation. The final idea was the help of a "merge monkey" someone who could assist with the merging from vendor to snowglobe so that its not always merov, this could be multiple people taking it in turns etc, this was all up in the air and just ideas banded around at the meeting. Robin ___ 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] [POLICY] coding the TPV policy (was: Third party viewer policy: commencement date)
Let's see where this analogy takes us ... On 03/21/2010 06:24 PM, Kent Quirk (Q Linden) wrote: > Think of lawyers as people who write code in an underspecified language for a > buggy compiler, and you begin to understand why legalese is the way it is. Imagine you're a law student, almost finished with your studies. Imagine there is a publisher who's working on a book about some law topic. The special thing about that project is, that while the publisher's hired authors will write most of the book, an online community can participate and help writing some parts. As you've already learned quite a bit about the book's topic in your studies (you actually were familiar to it, even before that), you consider to join that endeavor. However, the book is written in a strange file format, so the publisher has to require you to use a special text editor they provide in binary and source. You aren't a coder, but you've recently taken a java course, so you decide to take a look into the code before running the program. It's written in C++. Looks close enough, you think, and actually you're able to understand most of the code. One expression has two post increments in it and you notice the final value would depend on execution order. Later, that value is used to decide whether a chunk of code is executed that looks like it might publish your address book on some server. Inline comments claim that that code isn't reachable, but you aren't too sure about that. Why is that code there, then, anyway? And why should a text editor have access to your address book? You decide to get some council, and ask a fellow law student who's done some more coding in her free time than you. She insists on stating that she isn't an MCSE before every advice she gives. You think that's rather silly, though her advice about avoiding "nasal demons" sounds reasonable. You ask the book publisher about the issue and whether they could take out that part of the code. They tell you to hire a C++ programmer, which (let's just assume that for now) is quite expensive. Prohibitively expensive even, for a student not yet earning his own money. There's a program where the IT students of your university offer free advice to non-IT students. You go there to ask them, assuming they can tell you more. It turns out they can't. They mostly help foreign students to understand MS Excel and OpenOffice.org Calc formulas, written for the German versions (which have different function names than the English one). Themselves they know neither English nor C++ very well. However they warn you that the importing of standard headers at the beginning of the code you show them might have some implications. They aren't sure which implications. Would you still launch that text editor? Boroondas ___ 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] Third party viewer policy: commencement date
Um yes... I cannot agree with this TPV (I explicitely don't). What we need is it to be either changed, or have a real lawyer look at it and explain the ramifications. What it says now is pretty clear to me: if I contribute to some GPL-ed third party viewer and later someone else uses it to connect to SL, while in the meantime LL has changed the TPV policy such that the viewer is now in violation with it, then the FBI will be knocking on my door to cash-in $1000,000 of damages. At least that would be possible with the current wording. Ban me if you have to, but I don't agree with it. If ever I had to click "yes I agree" in order to connect, then sure as hell I won't. I will change the viewer code and remove that agreement (as is allowed per the GPL), then I will recompile and reconnect WITHOUT agreeing. Breaking the TPV policy, but at least I won't have agreed with it. On Mon, Mar 22, 2010 at 12:53:35PM +0100, Lance Corrimal wrote: > Am Montag, 22. März 2010 12:44:57 schrieb Carlo Wood: > > I'd like to see this question answered, too. > > > > On Sun, Mar 21, 2010 at 06:08:58PM +0200, Ryan McDougall wrote: > > > The policy deeply confuses users and developers together, making it > > > appear to me that "users" can place "developers" in violation of your > > > policy against their will. > > > > > > Let me explain: > > > > > > Let's say I develop a client expressly designed to log into OpenSim > > > for example. Because of protocol compatibility, this client is > > > incidentally capable of logging into SL. If a user decides to to just > > > that, he is *clearly* a "User of Third Party Viewer". However, has he > > > just made me a "Developer of Third Party Viewer"? I see no language > > > that protects me from your policy. > > > > > > I've no interest in using LL's servers or enabling LL's business > > > model. I don't want to agree to the TVP. Has OpenSim's historical > > > choice of protocol placed it under LL's legal domain? If not, what > > > section of your policy protects me? > > > > > > Sincerely, > > > Ryan > > Let's face it. > Q has basically put a final answer to all our questions. > > how did he put it... "Similarly, any comment by one of Linden's lawyers in > this forum or any other could possibly be treated as legally binding. That > also goes for Linden employees, especially those with any seniority. So > you're > unlikely to get further remarks or "clarifications", except general > statements > that don't address specific questions. The policy was revised based on > comments on this list and elsewhere. That's probably a pretty good indication > that Linden Lab's lawyers now think it's clear enough to state its intent and > to stand up in court if they need it to." > > > therefor I notified the FSF of this stuff. > Let's see what they think. > ___ > 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 -- Carlo Wood ___ 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] [POLICY] coding the TPV policy (was: Third party viewer policy: commencement date)
Am Montag, 22. März 2010 16:47:39 schrieb Boroondas Gupte: > > Would you still launch that text editor? > > Boroondas ...no. ___ 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] Third party viewer policy: commencement date
Policy and license (or else) change aren't retroactive, never -- Sent by iPhone Il giorno 22/mar/2010, alle ore 16.51, Carlo Wood ha scritto: > Um yes... I cannot agree with this TPV (I explicitely don't). > What we need is it to be either changed, or have a real > lawyer look at it and explain the ramifications. > > What it says now is pretty clear to me: if I contribute > to some GPL-ed third party viewer and later someone else > uses it to connect to SL, while in the meantime LL has > changed the TPV policy such that the viewer is now in > violation with it, then the FBI will be knocking on > my door to cash-in $1000,000 of damages. > > At least that would be possible with the current wording. > Ban me if you have to, but I don't agree with it. If ever > I had to click "yes I agree" in order to connect, then > sure as hell I won't. I will change the viewer code and > remove that agreement (as is allowed per the GPL), then I > will recompile and reconnect WITHOUT agreeing. Breaking > the TPV policy, but at least I won't have agreed with it. > > On Mon, Mar 22, 2010 at 12:53:35PM +0100, Lance Corrimal wrote: >> Am Montag, 22. März 2010 12:44:57 schrieb Carlo Wood: >>> I'd like to see this question answered, too. >>> >>> On Sun, Mar 21, 2010 at 06:08:58PM +0200, Ryan McDougall wrote: The policy deeply confuses users and developers together, making it appear to me that "users" can place "developers" in violation of your policy against their will. Let me explain: Let's say I develop a client expressly designed to log into OpenSim for example. Because of protocol compatibility, this client is incidentally capable of logging into SL. If a user decides to to just that, he is *clearly* a "User of Third Party Viewer". However, has he just made me a "Developer of Third Party Viewer"? I see no language that protects me from your policy. I've no interest in using LL's servers or enabling LL's business model. I don't want to agree to the TVP. Has OpenSim's historical choice of protocol placed it under LL's legal domain? If not, what section of your policy protects me? Sincerely, Ryan >> >> Let's face it. >> Q has basically put a final answer to all our questions. >> >> how did he put it... "Similarly, any comment by one of Linden's >> lawyers in >> this forum or any other could possibly be treated as legally >> binding. That >> also goes for Linden employees, especially those with any >> seniority. So you're >> unlikely to get further remarks or "clarifications", except general >> statements >> that don't address specific questions. The policy was revised based >> on >> comments on this list and elsewhere. That's probably a pretty good >> indication >> that Linden Lab's lawyers now think it's clear enough to state its >> intent and >> to stand up in court if they need it to." >> >> >> therefor I notified the FSF of this stuff. >> Let's see what they think. >> ___ >> 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 > > -- > Carlo Wood > ___ > 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] Third party viewer policy: commencement date
On Sun, Mar 21, 2010 at 5:24 PM, Kent Quirk (Q Linden) wrote: > I'm emphatically not a lawyer and I don't speak for our legal team. But: > > * Legalese is a specialized language. It's not strictly English, and it's > not always amenable to "common sense" interpretation. Think of lawyers as > people who write code in an underspecified language for a buggy compiler, > and you begin to understand why legalese is the way it is. There's a lot of > law that isn't stated, but is actually implied by the context of the > existing settled law. What that means is that if you're not a lawyer, you > probably shouldn't be attempting to interpret legal documents -- especially > not for other people[cut]. If you have legal questions about the > implication of documents, you should ask a lawyer, not a mailing list. This paraphrases quite accurately as "Our lawyers can write any old nonsense and you or I cannot question it, because the language of lawyers is beyond our comprehension." If you truly believe the words you wrote (not my paraphrasing), then I'm not surprised that you are in such deep trouble with this community which is well versed in GPL license legalities. If your statement is accurate, then your lawyers are effectively out of control by anyone in the Lab who is not a lawyer. I recommend that you shed your inferiority complex with respect to lawyers, and TELL THEM what you want written, not vice versa. The tail is wagging the dog currently. Morgaine. On Sun, Mar 21, 2010 at 5:24 PM, Kent Quirk (Q Linden) wrote: > I'm emphatically not a lawyer and I don't speak for our legal team. But: > > * Legalese is a specialized language. It's not strictly English, and it's > not always amenable to "common sense" interpretation. Think of lawyers as > people who write code in an underspecified language for a buggy compiler, > and you begin to understand why legalese is the way it is. There's a lot of > law that isn't stated, but is actually implied by the context of the > existing settled law. What that means is that if you're not a lawyer, you > probably shouldn't be attempting to interpret legal documents -- especially > not for other people. Similarly, if you're not a programmer, attempting to > interpret program source code is a risky business. Programmers are > especially susceptible to trying to interpret legal documents using a normal > dictionary because they're logical thinkers. That doesn't always work. If > you have legal questions about the implication of documents, you should ask > a lawyer, not a mailing list. > > * Similarly, any comment by one of Linden's lawyers in this forum or any > other could possibly be treated as legally binding. That also goes for > Linden employees, especially those with any seniority. So you're unlikely to > get further remarks or "clarifications", except general statements that > don't address specific questions. The policy was revised based on comments > on this list and elsewhere. That's probably a pretty good indication that > Linden Lab's lawyers now think it's clear enough to state its intent and to > stand up in court if they need it to. > >Q > > On Mar 21, 2010, at 12:55 PM, Carlo Wood wrote: > > > On Sun, Mar 21, 2010 at 05:04:58PM +0100, Tayra Dagostino wrote: > >> maybe we cannot sync this isn't a restriction against development > >> based on GPL, is a restriction against ability to connect LL grid with > >> a 3rd party viewer... > > > > No it's not. If that were the case it would say "User", not "Developer". > > Also, I don't read "you will not be able to connect", I read "you will > > be liable for any damages". Quite a different thing. > > ___ > 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
[opensource-dev] 32 bit Official viewer 2 beta, Snowglobe binary (rev 3229) does't run 'out of the box'
For awhile, I was able to download the Snowglobe binary and run it on my Debian Lenny system. Now this didn't work with the latest Official release binary and snowglobe binary. Actually, it's the included 32 bit libraries themselves that cause a problem which gives an assertion failure when started. It's either libc6 or libopenal, or maybe another. (not easy to pinpoint without full trace) If I run the binary distribution on Debian Sid, it starts fine with no binary release. However, it's not practical to require us to use Debian Sid to run a binary, as that means the release has inherited 'unstable'-ness. My guess is someone must have re-compiled the 32 bit libs under Sid instead of under Lenny (or Etch). That would then have mess up the dependencies and cause the assertion failure above. Debian Sid did recently upgrade it's libc6 (and c++ versions) from 4.3 to 4.4. Can LL please fix/double-check the 32 bit libs (linked and dso) of the 32 bit Official viewer 2 beta and Snowglobe binaries, so that they work under 32 bit Lenny without assertion failures. ___ 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] Open Development project: extending avatar wearables
Greetings Opensource-dev! This tiny robot is going to be working over the next few weeks to begin working on the next iteration of avatar features, and needs your help! We're hoping to continue our overhaul of how you manage your appearance. Since we're shooting for moving towards quarterly releases, there's a lot of work to be done! I'll be setting up a sub-form for collaboration and discussion of designs, as well as working on cleaning up some initial design concepts for how the user interface will be presented - I'll follow up on this list with links to the documents when they're online. Some of the features we want to implement: 1) A new panel to edit what is stored in your saved outfit without creating a new one. This will include both an inventory view and a view of your outfit itself, so you can drag items from your inventory to your outfit without having an extra floater open 2) Editing of wearable items (body parts and/or clothing objects) in the sidebar, selectable from the outfit editor 3) Removal of the appearance floater 4) Order-specific outfits with the ability to re-order wearables as desired 5) Ability to wear multiple wearables of the same type (multiple shirts, multiple jackets and yes, multiple alpha masks!). I look forward to working with everyone and getting a lot of feedback throughout the development process. I'll be releasing a lot more detailed information as I can get it formatted and out the door. There are just a handful of things to keep in mind. First, this is still a featureset developed by Linden Lab, which has a few implications. If there is a dispute, we will hold final say on what goes into the client we ship. There will not always be perfect consensus on every decision made, but I will try to be more transparent about what decisions we make and why, where appropriate. Also, since the code for this feature will be in the main second-life viewer, we do still require a signed CLA before we can integrate your patches into our codebase. Second, I ask that we all do what we can to keep the discussion civil and collaborative. The tiny robot cloning machine still isn't working right yet, so there is only one of me and I'll make the time to collaborate with everyone who wants to help with creating a more robust featureset that will ship in the time we have to develop it. Posts for ideas that we don't have the time or resource to implement, rants, or non-constructive feedback will receive significantly less attention. Once the forums are up, I'll post there with details of what infrastructure is currently in place, what our initial designs are, and how best to give feedback. Once we get our new branch structure in place, I'll be doing all of my checkins in the open and will be pulling in community contributions on a regular basis. I look forward to working with the community on this project and providing a positive examples to encourage other internal projects to work more directly with the community! -Nyx ___ 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] Open Development project: extending avatar wearables
On Mon, Mar 22, 2010 at 6:45 PM, Nyx Linden wrote: > Greetings Opensource-dev! [snip] > Some of the features we want to implement: > 1) A new panel to edit what is stored in your saved outfit without > creating a new one. > This will include both an inventory view and a view of your outfit > itself, so you can drag items from your inventory to your outfit without > having an extra floater open > 2) Editing of wearable items (body parts and/or clothing objects) in the > sidebar, selectable from the outfit editor > 3) Removal of the appearance floater > 4) Order-specific outfits with the ability to re-order wearables as desired > 5) Ability to wear multiple wearables of the same type (multiple shirts, > multiple jackets and yes, multiple alpha masks!). Awesome set of features! My suggestion would be to create a Jira (or a Wiki page) with the proposed look of the new appearance manager functions, and post pictures with interface mockups, and encourage people to come up with their own suggestions for improvements in form of interface mockups. Latif ___ 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] Open Development project: extending avatar wearables
Nyx Linden wrote: > Some of the features we want to implement: > 1) A new panel to edit what is stored in your saved outfit without > creating a new one. > This will include both an inventory view and a view of your outfit > itself, so you can drag items from your inventory to your outfit without > having an extra floater open > 2) Editing of wearable items (body parts and/or clothing objects) in the > sidebar, selectable from the outfit editor > 3) Removal of the appearance floater > 4) Order-specific outfits with the ability to re-order wearables as desired > 5) Ability to wear multiple wearables of the same type (multiple shirts, > multiple jackets and yes, multiple alpha masks!). > All these features could be contained in an app or client-side script outside the main viewer. This is one of the reasons why I wanted to develop SNOW-375: https://jira.secondlife.com/browse/SNOW-375 This new "detailed" appearance UI doesn't need to be in the viewer at all. The basic Inventory UI can stay built-in to the viewer in order to provide default functionality. I recently added methods to access inventory items through the REST/HTTP interface. I don't want to spill all details at this time, yet scriptable access to the inventory could, for example, read a notecard that then reads all the layered composites (texture UUIDs) to bake on the avatar. Then the script does a POST or PUT with the final composite to trigger the baked upload. I'd probably be done with such a UI if my disability didn't slow me down. =( Anyways, do look at these galleries carefully to notice the level of detail for avatars that I have kept in mind: http://igolochka.deviantart.com/gallery/ http://opalseadragon.deviantart.com/gallery/ Things to note off hand: 1) level of detail to the composite skin layers and immediate clothes layer 2) level of detail of the physics of the clothes how (they pass over the skin and not through the skin) 3) level of detail of the fingers and toes, and close-ups of facial features The main renderer of the viewer may not include such detail because of practicality of speed, yet when someone examines a person's profile, then these kinds of details could be rendered. A "snapshot" could also become much more higher quality if the rest of these details were filled in just for the pose. ___ 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] Open Development project: extending avatar wearables
Nyx, it's excellent news that you're starting this open development project. Well done! There's one thing to keep in mind though, so that it doesn't come as a surprise to anyone at the Lab (no surprise to yourself of course). When development is open and many community teams are involved, some teams will implement features before other teams do. This is great, as everyone can take code from everyone else, and the net result is that individual developers do less work. Yay! Unfortunately, LL has a Contributor's Agreement, and as a result of that appalling document, everyone can take freely from LL's code while LL cannot take freely from other teams' code, BY YOUR OWN CHOICE. This means that Lindens will end up reinventing wheels and doing much more work than need be, and your viewer will lag behind that of other teams. The above situation is extremely bad for Linden Lab, and for wear and tear on your tiny robot. Before you reply with the usual hints that "Developers are powerless about policy in LL", I would offer that your *Tao of Linden* gives you the freedom to question everything and everyone in the Lab. If you wished to do so, it would allow you to highlight that the benefits of that Contrib Agreement are extremely small or non-existent, while its cost to LL and to yourself is extremely high. You have the power to make your lawyers work *for* you, rather than against you, if you wish to exercise it. Well done on taking this strong step towards open development! Morgaine. On Mon, Mar 22, 2010 at 5:45 PM, Nyx Linden wrote: > Greetings Opensource-dev! > >This tiny robot is going to be working over the next few weeks to > begin working on the next iteration of avatar features, and needs your > help! > We're hoping to continue our overhaul of how you manage your appearance. > Since we're shooting for moving towards quarterly releases, there's a > lot of work to be done! > > I'll be setting up a sub-form for collaboration and discussion of > designs, as well as working on cleaning up some initial design concepts > for how the user interface will be presented - I'll follow up on this > list with links to the documents when they're online. > > Some of the features we want to implement: > 1) A new panel to edit what is stored in your saved outfit without > creating a new one. >This will include both an inventory view and a view of your outfit > itself, so you can drag items from your inventory to your outfit without > having an extra floater open > 2) Editing of wearable items (body parts and/or clothing objects) in the > sidebar, selectable from the outfit editor > 3) Removal of the appearance floater > 4) Order-specific outfits with the ability to re-order wearables as desired > 5) Ability to wear multiple wearables of the same type (multiple shirts, > multiple jackets and yes, multiple alpha masks!). > > I look forward to working with everyone and getting a lot of feedback > throughout the development process. I'll be releasing a lot more > detailed information as I can get it formatted and out the door. There > are just a handful of things to keep in mind. > > First, this is still a featureset developed by Linden Lab, which has a > few implications. If there is a dispute, we will hold final say on what > goes into the client we ship. There will not always be perfect consensus > on every decision made, but I will try to be more transparent about what > decisions we make and why, where appropriate. Also, since the code for > this feature will be in the main second-life viewer, we do still require > a signed CLA before we can integrate your patches into our codebase. > > Second, I ask that we all do what we can to keep the discussion civil > and collaborative. The tiny robot cloning machine still isn't working > right yet, so there is only one of me and I'll make the time to > collaborate with everyone who wants to help with creating a more robust > featureset that will ship in the time we have to develop it. Posts for > ideas that we don't have the time or resource to implement, rants, or > non-constructive feedback will receive significantly less attention. > > Once the forums are up, I'll post there with details of what > infrastructure is currently in place, what our initial designs are, and > how best to give feedback. Once we get our new branch structure in > place, I'll be doing all of my checkins in the open and will be pulling > in community contributions on a regular basis. I look forward to working > with the community on this project and providing a positive examples to > encourage other internal projects to work more directly with the community! > > -Nyx > ___ > 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] 32 bit Official viewer 2 beta, Snowglobe binary (rev 3229) does't run 'out of the box'
What is the assertion failure? -- Carlo Wood ___ 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] 32 bit Official viewer 2 beta, Snowglobe binary (rev 3229) does't run 'out of the box'
Carlo Wood wrote: > What is the assertion failure? > > This is the error right after one types in "./snowglobe" or "./secondlife" to run the startup script: Inconsistency detected by ld.so: dl-open.c: 643: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed! Note that libwrap does exist in lenny or squeeze, only in etch and sid: http://packages.debian.org/etch/libwrap-dev With "LD_DEBUG=versions", here is part of the output: 19683: 19683: 19683:calling init: /home/dzonatas/Desktop/S/Snowglobe-i686-1.4.0.0/lib/libopenal.so.1 19683: Inconsistency detected by ld.so: dl-open.c: 643: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed! *** Bad shutdown. *** 19684:checking for version `GLIBC_2.3' in file /lib/libc.so.6 [0] required by file uname [0] 19684:checking for version `GLIBC_2.2.5' in file /lib/libc.so.6 [0] required by file uname [0] 19684:checking for version `GLIBC_PRIVATE' in file /lib64/ld-linux-x86-64.so.2 [0] required by file /lib/libc.so.6 [0] 19684:checking for version `GLIBC_2.3' in file /lib64/ld-linux-x86-64.so.2 [0] required by file /lib/libc.so.6 [0] 19684: 19684:calling init: /lib/libc.so.6 With "LD-DEBUG=versions,libs", here is part of the output: 19583: 19583:find library=libwrap.so.0 [0]; searching 19583: search path=/home/dzonatas/Desktop/S/Snowglobe-i686-1.4.0.0/lib:tls/i686/sse2/cmov:tls/i686/sse2:tls/i686/cmov:tls/i686:tls/sse2/cmov:tls/sse2:tls/cmov:tls:i686/sse2/cmov:i686/sse2:i686/cmov:i686:sse2/cmov:sse2:cmov: (LD_LIBRARY_PATH) 19583: trying file=/home/dzonatas/Desktop/S/Snowglobe-i686-1.4.0.0/lib/libwrap.so.0 19583: trying file=tls/i686/sse2/cmov/libwrap.so.0 19583: trying file=tls/i686/sse2/libwrap.so.0 19583: trying file=tls/i686/cmov/libwrap.so.0 19583: trying file=tls/i686/libwrap.so.0 19583: trying file=tls/sse2/cmov/libwrap.so.0 19583: trying file=tls/sse2/libwrap.so.0 19583: trying file=tls/cmov/libwrap.so.0 19583: trying file=tls/libwrap.so.0 19583: trying file=i686/sse2/cmov/libwrap.so.0 19583: trying file=i686/sse2/libwrap.so.0 19583: trying file=i686/cmov/libwrap.so.0 19583: trying file=i686/libwrap.so.0 19583: trying file=sse2/cmov/libwrap.so.0 19583: trying file=sse2/libwrap.so.0 19583: trying file=cmov/libwrap.so.0 19583: trying file=libwrap.so.0 19583: search cache=/etc/ld.so.cache 19583: search path=/lib32/tls/i686/sse2/cmov:/lib32/tls/i686/sse2:/lib32/tls/i686/cmov:/lib32/tls/i686:/lib32/tls/sse2/cmov:/lib32/tls/sse2:/lib32/tls/cmov:/lib32/tls:/lib32/i686/sse2/cmov:/lib32/i686/sse2:/lib32/i686/cmov:/lib32/i686:/lib32/sse2/cmov:/lib32/sse2:/lib32/cmov:/lib32:/usr/lib32/tls/i686/sse2/cmov:/usr/lib32/tls/i686/sse2:/usr/lib32/tls/i686/cmov:/usr/lib32/tls/i686:/usr/lib32/tls/sse2/cmov:/usr/lib32/tls/sse2:/usr/lib32/tls/cmov:/usr/lib32/tls:/usr/lib32/i686/sse2/cmov:/usr/lib32/i686/sse2:/usr/lib32/i686/cmov:/usr/lib32/i686:/usr/lib32/sse2/cmov:/usr/lib32/sse2:/usr/lib32/cmov:/usr/lib32:/lib/i486-linux-gnu/tls/i686/sse2/cmov:/lib/i486-linux-gnu/tls/i686/sse2:/lib/i486-linux-gnu/tls/i686/cmov:/lib/i486-linux-gnu/tls/i686:/lib/i486-linux-gnu/tls/sse2/cmov:/lib/i486-linux-gnu/tls/sse2:/lib/i486-linux-gnu/tls/cmov:/lib/i486-linux-gnu/tls:/lib/i486-linux-gnu/i686/sse2/cmov:/lib/i486-linux-gnu/i686/sse2:/lib/i486-linux-gnu/i686/cmov:/lib/i486-linux-gnu/i686:/lib/i486-linux-gnu/sse2/cmov:/lib/i486-linux-gnu/sse2:/lib/i486-linux-gnu/cmov:/lib/i486-linux-gnu:/usr/lib/i486-linux-gnu/tls/i686/sse2/cmov:/usr/lib/i486-linux-gnu/tls/i686/sse2:/usr/lib/i486-linux-gnu/tls/i686/cmov:/usr/lib/i486-linux-gnu/tls/i686:/usr/lib/i486-linux-gnu/tls/sse2/cmov:/usr/lib/i486-linux-gnu/tls/sse2:/usr/lib/i486-linux-gnu/tls/cmov:/usr/lib/i486-linux-gnu/tls:/usr/lib/i486-linux-gnu/i686/sse2/cmov:/usr/lib/i486-linux-gnu/i686/sse2:/usr/lib/i486-linux-gnu/i686/cmov:/usr/lib/i486-linux-gnu/i686:/usr/lib/i486-linux-gnu/sse2/cmov:/usr/lib/i486-linux-gnu/sse2:/usr/lib/i486-linux-gnu/cmov:/usr/lib/i486-linux-gnu (system search path) 19583: trying file=/lib32/tls/i686/sse2/cmov/libwrap.so.0 19583: trying file=/lib32/tls/i686/sse2/libwrap.so.0 19583: trying file=/lib32/tls/i686/cmov/libwrap.so.0 19583: trying file=/lib32/tls/i686/libwrap.so.0 19583: trying file=/lib32/tls/sse2/cmov/libwrap.so.0 19583: trying file=/lib32/tls/sse2/libwrap.so.0 19583: trying file=/lib32/tls/cmov/libwrap.so.0 19583: trying file=/lib32/tls/libwrap.so.0 19583: trying file=/lib32/i686/sse2/cmov/libwrap.so.0 19583: trying file=/lib32/i686/sse2/libw
Re: [opensource-dev] Open Development project: extending avatar wearables
While you are working in this area one killer feature would be to have a way to create a "base outfit" list colors and then have the program create copies with each color (looking at the xml export files this would be just a matter of UUID patching and flipping 3 fields in the data) Bonus points if the color picker understood HTML 4.01 named colors -- Robert L Martin ___ 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] Third party viewer policy: commencement date
+1 Mike Jesse Barnett wrote: > Jeez I fail to understand why in the heck LL can not understand this > simple concept. > > Linden devs have introduced bugs before that have allowed content to be > stolen, no mod scripts to be readable, and inventories worth several > hundred dollars to vanish overnight. Yet, none of you, under the terms > of your employment, are legally liable for this nor do you have to > compensate for the losses out of your pocket. > > Would any Linden here sign a document stating that you are personally > liable for your code?? > > Would you sign a document stating that if you introduced another bug > that makes inventories vanish that you have to pay all the affected > parties back > > Would you sign a document that is worded so poorly that you then have to > create a FAQ for that same document but the FAQ is in itself > non-binding, only the original, poorly worded contract? > > Please take off the rose colored glasses and read it again as if YOU had > to sign it, then you will begin to understand the considerable amount of > unease that the community is experiencing at the moment. > > Jesse Barnett ___ 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] Open Development project: extending avatar wearables
Nyx, would you be willing to come to the User Experience Interest Group meeting, Thursdays from 3-4PM at Hippotropolis ( http://slurl.com/secondlife/Hippotropolis/43/104/25 ), or share your thoughts on the sl-ux mailing list? Jacek Antonelli (copied here) is the moderator of the UXIG meeting. (cross posting to sl-ux) Mike Nyx Linden wrote: > Greetings Opensource-dev! > > This tiny robot is going to be working over the next few weeks to > begin working on the next iteration of avatar features, and needs your help! > We're hoping to continue our overhaul of how you manage your appearance. > Since we're shooting for moving towards quarterly releases, there's a > lot of work to be done! ___ 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] Open Development project: extending avatar wearables
Hi Mike, I'm already on sl-ux and will keep an eye on it when I have the time. I'll defer most discussion and decision making to a central location (probably the forums & wiki), but would be happy to come to a group meeting if my schedule permits (that's a little late for my timezone, but not unreasonably so) to discuss the project. If I'm unable to attend, I'll send a mail to the sl-ux list explaining the project and where people can go for more info. Let me know if you have any specific concerns or requests. -Nyx Mike Monkowski wrote: > Nyx, would you be willing to come to the User Experience Interest > Group meeting, Thursdays from 3-4PM at Hippotropolis ( > http://slurl.com/secondlife/Hippotropolis/43/104/25 ), or share your > thoughts on the sl-ux mailing list? Jacek Antonelli (copied here) is > the moderator of the UXIG meeting. > > (cross posting to sl-ux) > > Mike > > Nyx Linden wrote: >> Greetings Opensource-dev! >> >> This tiny robot is going to be working over the next few weeks to >> begin working on the next iteration of avatar features, and needs >> your help! >> We're hoping to continue our overhaul of how you manage your >> appearance. Since we're shooting for moving towards quarterly >> releases, there's a lot of work to be done! ___ 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] Open Development project: extending avatar wearables
On 2010-03-22, at 12:45, Nyx Linden wrote: > 1) A new panel to edit what is stored in your saved outfit without > creating a new one. >This will include both an inventory view and a view of your outfit > itself, so you can drag items from your inventory to your outfit > without > having an extra floater open > 2) Editing of wearable items (body parts and/or clothing objects) in > the > sidebar, selectable from the outfit editor > 3) Removal of the appearance floater I have a concern about this, where it comes to editing outfits containing prim parts. You have to see them in world, you can't just edit them in a sidebar window, because you may need to edit them with reference to objects in world. If I'm mistaken about what "removal of the appearance floater" means, in the context of a UI designed to allow you to edit outfits without having to wear them, then I'll be happy to be corrected. ___ 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] Open Development project: extending avatar wearables
Good question! There is still a lot of detail left out of these descriptions, but we are planning on moving the UI in the appearance editor into the sidebar, along with creating a new outfit editor UI. You will still see the results of the changes you are making on your avatar in-world in real time. There will still be an "editing appearance" mode as you have now, it will just be accompanied by a panel in the sidebar instead of a separate floater. - Nyx On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter wrote: > > On 2010-03-22, at 12:45, Nyx Linden wrote: > >> 1) A new panel to edit what is stored in your saved outfit without >> creating a new one. >> This will include both an inventory view and a view of your outfit >> itself, so you can drag items from your inventory to your outfit without >> having an extra floater open >> 2) Editing of wearable items (body parts and/or clothing objects) in the >> sidebar, selectable from the outfit editor >> 3) Removal of the appearance floater >> > > I have a concern about this, where it comes to editing outfits containing > prim parts. You have to see them in world, you can't just edit them in a > sidebar window, because you may need to edit them with reference to objects > in world. > > If I'm mistaken about what "removal of the appearance floater" means, in > the context of a UI designed to allow you to edit outfits without having to > wear them, then I'll be happy to be corrected. > > ___ 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] Open Development project: extending avatar wearables
All interesting ideas, but it would be prudent to include a floater as an option. Not only will it make things easier on experienced users and those who don't like the sidebar, it will make things easier for the devs making versions of Viewer 2.0 for photo-sensitive people to use without issue. Maya Nyx Linden wrote: > Good question! There is still a lot of detail left out of these > descriptions, but we are planning on moving the UI in the appearance > editor into the sidebar, along with creating a new outfit editor UI. > You will still see the results of the changes you are making on your > avatar in-world in real time. There will still be an "editing > appearance" mode as you have now, it will just be accompanied by a > panel in the sidebar instead of a separate floater. > > - Nyx > > On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter > mailto:secret.arg...@gmail.com>> wrote: > > > On 2010-03-22, at 12:45, Nyx Linden wrote: > > 1) A new panel to edit what is stored in your saved outfit without > creating a new one. > This will include both an inventory view and a view of your > outfit > itself, so you can drag items from your inventory to your > outfit without > having an extra floater open > 2) Editing of wearable items (body parts and/or clothing > objects) in the > sidebar, selectable from the outfit editor > 3) Removal of the appearance floater > > > I have a concern about this, where it comes to editing outfits > containing prim parts. You have to see them in world, you can't > just edit them in a sidebar window, because you may need to edit > them with reference to objects in world. > > If I'm mistaken about what "removal of the appearance floater" > means, in the context of a UI designed to allow you to edit > outfits without having to wear them, then I'll be happy to be > corrected. > > > > > ___ > 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] Moving forward with open development
On Sun, Mar 21, 2010 at 11:42 AM, JB Hancroft wrote: > I'm concerned that there are so many divergent viewer projects, that the > end-user experience is going to be fractured. > What happens when I want "this shiny new thing" (available only with the ABC > viewer), and "that other shiny" (available only with the XYZ viewer)? > > I'd like to avoid this, in the future: > (Person 1: "Oh, you Don't Have the RubyShine-on-steroids plugin for > Snowglobe? <*smirk*> > Well, Everyone Knows... you just can't enjoy > high-end SL jewelry without it." > Person 2: "Well, yeah, but I have to choose between my Super-Gizmo > Estate Mgmt Viewer, and awesome jewelry... Sigh") > I think this is an unavoidable consequence of open source. If LL hired more developers and implemented all the new things that have appeared in third-party viewers, then the third-party viewers would just build on top of that and add even more new features. Think of it like this: the official viewer is developed by 42 (I just made this up) developers. Third-party viewers are developed by those same 42 developers, plus more people! So third-party viewers are always going to be a step ahead, no matter how much effort LL puts in to keep up, the third-party viewers are always building on top of that. If you're implying that we have all these third-party viewers because the process of getting patches accepted into the official viewer is difficult, I'm not going to disagree with you. It could be a lot easier, and if it were some of these people might have contributed their code to the official viewer instead of spawning a third-party viewer. But look at any open source project, even the most open ones. There's always going to be someone that decides they don't want to contribute back to the original program, they want to fork it and develop on their own. Colin ___ 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] "vendor" branch and Snowglobe 2.0
Hi Carlo, On Thu, Mar 18, 2010 at 4:19 AM, Carlo Wood wrote: > On Wed, Mar 17, 2010 at 05:52:55PM -0700, Philippe (Merov) Bossut wrote: > > Long Story > > I'm pretty much done with all the export script writing now and I'm > moving to > > make all that live so that updates from the viewer trunk come in more > regularly > > and automatically. > > "regulary" doesn't mean that commits by internal developers are merged > before committed, or that their commit messages are lost, is it? > > Ie, if at 15:00 Foobar Linden commits 5 lines with the text "Don't sleep(1) > here", > then I'm happy with that being delayed 24 hours, but I'd really still > like to see it committed to snowglobe (whatever trunk) as a single > commit of 5 lines with the same comment (and WHO did that commit). > The export to the vendor branch will be frequent, at least daily, possibly for each successfully building commit so we avoid breakage. Since we're exporting from hg to svn, we needed to write some script to extract those messages and add them to the commit message. We worked on that over the weekend with CG and I tested today that it's working. Still, when doing svn merge weekly on the Snowglobe trunk, those messages are lost again. This is annoying. I've been toying with the idea of ditching svn after all and use hg also for the exported repo. This is pain though since it's really not an 'hg clone' (not possible in the current state of the internal repo) but at least it will make the message issue disappear when pulling the vendor branch in the trunk. The more I think about it, the more I think it's a better idea despite the annoying export step. That'd definitely be closer to what you're describing. Cheers, - Merov ___ 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] Open Development project: extending avatar wearables
Could you please stop putting everything into that sidebar as the only way to access stuff. You¹ve kept wanting to make this ³communicator window ³ before into a single un-detachable block. And despite many of use hating it and asking for you to make separate floaters, (or at least give us that option), you keep attaching everything all together again in that sidebar. This is an ill conceived approach for many of us, who are used to identify specific panels at a specific position of our choice on the screen just like . Blending it all together makes it harder in that sense. I recall LL hiring a guy who worked on the Tivo interface which is a great one for its purpose. But the viewer is a much more complex interface. I see too much of the Tivo formula into this ³drawer². The worse part is that the sidebar buttons are stuck on the left side and actual move with the sidebar panel itself. That seems wrong. Button should stay at the same place on the right in an Adobe fashion for distinction purpose. I wish you had studied and adopted the approach of the Adobe UIs with stackable and detachable panels and buttons on the right side (which always stay there). Their approach is a much better solution in my view that this drawer type, which is a huge waste of space right now and adding to the required amount of clicks to get somewhere. In short, please reserve an option for detachable floaters as much as possible, and please consider the Adobe approach for a more flexible and customizable sidebar(s) for Version 2.x.x Thank you On 3/22/10 8:06 PM, "Nyx Linden" wrote: > Good question! There is still a lot of detail left out of these descriptions, > but we are planning on moving the UI in the appearance editor into the > sidebar, along with creating a new outfit editor UI. You will still see the > results of the changes you are making on your avatar in-world in real time. > There will still be an "editing appearance" mode as you have now, it will just > be accompanied by a panel in the sidebar instead of a separate floater. > > - Nyx > > On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter > wrote: >> >> On 2010-03-22, at 12:45, Nyx Linden wrote: >>> 1) A new panel to edit what is stored in your saved outfit without >>> creating a new one. >>> This will include both an inventory view and a view of your outfit >>> itself, so you can drag items from your inventory to your outfit without >>> having an extra floater open >>> 2) Editing of wearable items (body parts and/or clothing objects) in the >>> sidebar, selectable from the outfit editor >>> 3) Removal of the appearance floater >> >> I have a concern about this, where it comes to editing outfits containing >> prim parts. You have to see them in world, you can't just edit them in a >> sidebar window, because you may need to edit them with reference to objects >> in world. >> >> If I'm mistaken about what "removal of the appearance floater" means, in the >> context of a UI designed to allow you to edit outfits without having to wear >> them, then I'll be happy to be corrected. >> > > > > ___ > 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] Request for clarification on mailing list guidelines
Hi, Each tool has its pluses and minuses and we use a variety of them: - Mailing list: may be the most widely used tool. The problem I see with it is that it mixes everything: small requests, long discussions, policies, technicalities, etc... Other FLOSS projects use a variety of lists, breaking things in categories (Mozilla for instance). It tends to become another kind of mess with cross posting. Yes, Gmail rocks and threaded discussions a god send but still... - wiki: it's one we underuse. The problem is that it needs a lot of wiki gardening and things can simply die there with no clear resolution. - IW meetings: we have our weekly Hippo meeting and I truly encourage folks to come. It's my favorite comm tool personally as it's a dedicated moment and we have full attention of everyone. Should we do more of this? - IRC: great for informal and quick discussions but *highly* distracting. I sometime choose not to be available so I can focus on work. - JIRA: great for focused technical discussions on features and bugs. The good thing is that one can manage something toward a resolution (as opposed to wiki) and redirect to other teams, link to other issues, etc... Yes, I like the JIRA despite everything. It's not appropriate for general discussions though. - Forum: there is actually one for Open Source ( https://blogs.secondlife.com/community/forums/open-source). I know that some folks at LL prefers this at it allows to create topics and sub threads more easily. I went there today and posted in some discussions. I think it's something we should use for specific discussions that would hijack the mailing list but are not mature for JIRA yet. Thoughts? Cheers, - Merov ___ 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] Open Development project: extending avatar wearables
On Tue, Mar 23, 2010 at 4:35 AM, Bryon Ruxton wrote: - Could you please stop putting everything into that sidebar as the only way to access stuff. You've kept wanting to make this "communicator window " before into a single un-detachable block. And despite many of use hating it and asking for you to make separate floaters, (or at least give us that option), you keep attaching everything all together again in that sidebar. This is an ill conceived approach for many of us, who are used to identify specific panels at a specific position of our choice on the screen just like . Blending it all together makes it harder in that sense. In addition to the fact that many people simply "do not like" the sidebar, there are several more technical reasons why it is a bad idea ergonomically too, such as limiting displays to only one type at a time (eg. not inventory AND friends) and only one instance at a time (e.g can't show two profiles). In addition, the continual movement and resizing shifts the 3D world in a very dizzying way, and chasing the '<<' tab across the screen breaks an elementary ergonomics rule for toggles and is very bad for accessibility, as well as extremely annoying. Given that the sidebar has so many problem and no advantages that have ever been defended, I suggest that the work should start by the sidebar advocates explaining the benefits that they see in the sidebar. Since this is an open development project, the community can weigh the advantages of the sidebar against its disadvantages, and if the advantages are lacking then the sidebar can be dropped and filed under "bad idea", or at least made optional. Although some people will probably suggest that the *real* likelihood of getting the sidebar dropped is nil, I think we should take the moral high ground here and assume that the sidebar too is subject to community feedback. Let's assume that this is an open development project in which advice from the community is considered seriously and in which engineering judgment and commonsense will prevail. What are the ergonomic / HI advantages of the sidebar? Morgaine. === On Tue, Mar 23, 2010 at 4:35 AM, Bryon Ruxton wrote: > Could you please stop putting everything into that sidebar as the only > way to access stuff. You’ve kept wanting to make this “communicator window “ > before into a single un-detachable block. And despite many of use hating it > and asking for you to make separate floaters, (or at least give us that > option), you keep attaching everything all together again in that sidebar. > This is an ill conceived approach for many of us, who are used to identify > specific panels at a specific position of our choice on the screen just like > . Blending it all together makes it harder in that sense. > > I recall LL hiring a guy who worked on the Tivo interface which is a great > one for its purpose. But the viewer is a much more complex interface. I see > too much of the Tivo formula into this “drawer”. The worse part is that the > sidebar buttons are stuck on the left side and actual move with the sidebar > panel itself. That seems wrong. Button should stay at the same place on the > right in an Adobe fashion for distinction purpose. > > I wish you had studied and adopted the approach of the Adobe UIs with > stackable and detachable panels and buttons on the right side (which always > stay there). Their approach is a much better solution in my view that this > drawer type, which is a huge waste of space right now and adding to the > required amount of clicks to get somewhere. > > In short, please reserve an option for detachable floaters as much as > possible, and please > consider the Adobe approach for a more flexible and customizable sidebar(s) > for Version 2.x.x > > Thank you > > > On 3/22/10 8:06 PM, "Nyx Linden" wrote: > > Good question! There is still a lot of detail left out of these > descriptions, but we are planning on moving the UI in the appearance editor > into the sidebar, along with creating a new outfit editor UI. You will still > see the results of the changes you are making on your avatar in-world in > real time. There will still be an "editing appearance" mode as you have now, > it will just be accompanied by a panel in the sidebar instead of a separate > floater. > > - Nyx > > On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter < > secret.arg...@gmail.com> wrote: > > > On 2010-03-22, at 12:45, Nyx Linden wrote: > > 1) A new panel to edit what is stored in your saved outfit without > creating a new one. >This will include both an inventory view and a view of your outfit > itself, so you can drag items from your inventory to your outfit without > having an extra floater open > 2) Editing of wearable items (body parts and/or clothing objects) in the > sidebar, selectable from the outfit editor > 3) Removal of the appearance floater > > > I have a concern about this, where it comes to editin
