[opensource-dev] Proposal: Howto add a new feature to snowglobe.

[Morgaine]

On Thu, Mar 18, 2010 at 5:30 PM, Tateru Nino <tateru.nino at gmail.com> wrote:

 > Huh. Curious. I have a client launcher (for SL among other things) called
'vwrap'.


I expect that before long, the prefix 'vw' will become as fashionable as 'e'
and now 'i'. ;-)

Morgaine.



===========================================

On Thu, Mar 18, 2010 at 5:30 PM, Tateru Nino <tateru.nino at gmail.com> wrote:

>  Huh. Curious. I have a client launcher (for SL among other things) called
> 'vwrap'.
>
>
> On 19/03/2010 4:23 AM, Morgaine wrote:
>
> Carlo, you're missing something very important in your write-up.
>
> The issue that you haven't covered is that Snowglobe is intended for
> interoperation with other worlds as well, not just with SL.  Our work in
> VWRAP <http://www.ietf.org/mail-archive/web/ogpx/current/maillist.html>has the goal of allowing a single client to work with any virtual world that
> can speak the protocol, and this applies very directly to Snowglobe.  Pixel
> has added new OGP functionality in this direction already as you know, and
> it is reasonable to expect that this code will be evolving further until
> Snowglobe speaks full VWRAP.
>
> What this means is that Snowglobe is not merely an SL viewer, but will
> allow any VWRAP compatible world to be visited ---  Lindens themselves agree
> on this direction.  You might like to read the article that three of us
> wrote recently for IEEE Internet Computing about the expected future of
> VWRAP, for which a Linden was co-author.  The article is available at:  VWRAP
> for Virtual Worlds Interoperability<http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual-Worlds-Interoperability-mic2010010073.pdf>
> .
>
> Needless to say, if virtual world travellers are to use Snowglobe in
> multiple VWs, then the viewer is going to have to do more than just handle
> the SL subset of functionality.  In other words, features for working with
> other worlds will also be appropriate in Snowglobe.  I confirmed that
> features for interoperability would be acceptable in Snowglobe *in
> principle*, back when Rob Linden was handling the Hippotropolis meetings.
> I assume that this is still the case, since Linden support of VWRAP remains
> as strong as ever.
>
> This doesn't mean that everything will go in of course, but it does mean
> that there will be features proposed which Linden Lab may not wish to merge
> back into their own SL viewer --- that would be perfectly normal.  Snowglobe
> developers who travel in virtual worlds will undoubtedly want to have a
> strong say in this, and even Lindens are quite likely to want to cherry-pick
> among such additional features for possible inclusion in the vendor branch.
> After all, it's reasonable to assume that LL doesn't want its main client to
> be left behind once we have interoperability.
>
> So the situation is rather more flexible than you suggest.  Snowglobe isn't
> only about working with SL, at least not until LL issues a restrictive
> policy which would make Snowglobe unpalatable for general VWRAP use.  I see
> no sign of that.
>
> Just to be sure that we're all on the same page, perhaps Merov would like
> to reaffirm Rob's statement regarding features that support interoperability
> in Snowglobe?  Since we don't actually have any particular features in mind
> at this time, it's more a general statement of principle and intent that
> matters at this stage.
>
>
> Morgaine.
>
>
>
>
>
>
>
> ==============================
>
> On Thu, Mar 18, 2010 at 12:02 PM, Carlo Wood <carlo at alinoe.com> wrote:
>
>> Here is some food for thought:
>>
>> -- Question: Who determines what is added to the viewer and what not?
>>
>> I propose (to be decided by Lindens, not others) the following:
>>
>> There are two different categories of things that can be added
>> to the viewer:
>>
>> Category 1: Bug fixes; intended behavior is not as expected.
>> Category 2: Features; intended behavior is changed (added).
>>
>> Category 1
>> ----------
>>
>> These are handled the same as category 2, but without the need
>> to decide at the user-experience level if the patch is wanted.
>> Thus, for *accepted* feature AND bug fix:
>>
>> A committer writes the patch.
>> The patch is reviewed by other committers.
>> No committer can stop a patch entirely, but they can request
>> patches to be taken back to the drawing board based on:
>>
>>  * CPU usage (FPS drop)
>>  * Memory usage
>>  * Coding style
>>  * Maintainability (how easy it is to make changes without breaking it)
>>  * Robustness (chance it breaks accidently by changes elsewhere)
>>
>> Committer are expected to work together and respect eachother,
>> but especially the original committer needs to be prepared to
>> spend another week or two to address each and every comment
>> made by other committers (for which the jira is used).
>>
>> When all other committers involved, with a minimum of one other
>> committer, are satisfied; the patch may be committed.
>>
>> Category 2
>> ----------
>>
>> In the case of a new feature, the new feature should really
>> first be discussed on this list, before being implemented.
>>
>> What is being discussed are the effects on the users, not
>> the technical effects like CPU usage etc. Non-committers
>> can (politely) provide insight and feedback, but do not
>> have any vote on whether or not a new feature will be added.
>>
>> In fact, nobody has a vote: in the end it's the call of
>> Linden Lab, where we assume that if any Linden speaks his/her
>> decision on the list that that is the internal decision of
>> Linden Lab (and another Linden will not suddenly oppose).
>>
>> Each feature must be carried by a committer. That is, someone
>> must step forward and offer to write it, test it and be
>> prepared to through the hassle of Catergory 1 above. In most
>> cases this will be a committer whose own idea the feauture
>> is, that is the advantage of putting time into actually
>> writing (good) patches. It is not a bad thing that committers
>> have this priveledge. Of course, it is also possible that
>> a committer decides to backup an idea of someone else.
>> [There is no reason he cannot be paid for that, but I expect
>> that in general this will not be the case].
>>
>> Linden Lab will take the following into account when making
>> their decision about a new feature:
>>
>> * This is about Snowglobe ONLY; whether or not it's also
>>  added to the official viewer is a separate issue.
>> * They will NOT take maintainability into account, that
>>  is the responsibility of the open source community.
>> * If the new feature has no last impact on the user
>>  base, which can always be achieved by making it optional
>>  and/or not the default, they will let themselves strongly
>>  be influenced by the consensus of the list discussion.
>> * The opinion of committers is taking more into account
>>  than the opinion of non-committers, because it's the
>>  committers who have to maintain the code.
>> * The decision is made in a timely manner (ie, within
>>  two weeks after the discussion on this list dies out).
>>  If no decision is communicated within a reasonable
>>  time, they right to a final decision forfeits and the
>>  feature may be added (all with gentlemen agreement of
>>  course).
>>
>> For example, the Life Cycle of a new feature might be
>> the following:
>>
>> * User thinks of new feature and adds it to the jira.
>> * Several people find it and vote for it.
>> * Feature comes to the attention of someone on this
>>  list and brings it under the attention of a committer.
>> * Committer commits himself (haha) and post to the list
>>  with implementation detail ideas.
>> * Everyone has their say in a civil and polite way.
>> * The design (on "paper") goes through a few cycles
>>  until the committer that committed himself doesn't
>>  want to make more changes.
>> * Linden Lab gives the red or green light.
>> * In case of a green light, the committer writes a
>>  patch and tests it. Then attaches it to the jira.
>> * At least one other committer tests it and makes
>>  comments about implementation details.
>> * Original committer rewrites the patch and/or
>>  fixes bugs, until all other committers that want
>>  to spend time on reviewing are satidfied.
>> * The patch is committed.
>>
>> --
>> Carlo Wood <carlo at 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
>
>
> --
> Tateru Ninohttp://dwellonit.taterunino.net/
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100318/313642d9/attachment.htm