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

Morgaine morgaine.dinova at googlemail.com
Thu Mar 18 10:23:44 PDT 2010


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100318/75ef6867/attachment.htm 


More information about the opensource-dev mailing list