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

[Tateru Nino]

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
> <mailto: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 <mailto: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 Nino
http://dwellonit.taterunino.net/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100319/72a1c8db/attachment-0001.htm