[sldev] OS-SL Development Issues (was Upcoming viewer releases)

[Harold Brown]

I think I can make some comments on the issues at hand as I have had
experiance with a simliar situation.

For anyone who has played Tribes or Tribes 2, I was fairly active in
scripting at the time using the nick LabRat.  As we all know Sierra killed
the Dynamix division and the Dynamix developers aquired the rights to the
source code and released it as Torque.  While Torque is not an OpenSource
application it does share many of the same characteristics.  As well as
having had the same troubles we're seeing now.

First of all it was a game engine written in-house, and had very little
documentation and lots of cruft left over from the various incarnations it
went through.  It was also developed internally and then source drops
provided for milestone releases, this was later phased over to a CVS
repository which was then phased back out with the CVS only suggested for
very advanced developers.

As for how it relates to an OpenSource project.  After you bought your
license... that's what it was... everyone worked together and contributed
code back to GarageGames to imporve the engine.  If they weren't fixing
bugs, they were writing doxygen documentation in the sourcecode for
functions so that more documentation would be available for other
developers.  Yes you had to have a contribution agreement to submit code
back into the engine, just like you need one for the OpenSource Second Life.

We had people who wanted to refactor the engine, to make it DLL's, people
who wanted to replace the scripting engine LUA, with python, etc.  People
who wanted to replace the entire GUI... and yes  GarageGames even worked on
features internally that were hidden from the other developers.

It took 3 years for all that to happen...  and people here are falling all
over each other complaining that the Lindens haven't gotten it right in 6
months?  That other OpenSource projects are better... well no shit, they
started out as OpenSource... they don't have to change everything that
they're used to do things how the community expects.

But yes... the Lindens do need to improve on things... communication is one
of them.  Yes the office hours are nice, I like to read Zero Lindens since I
can't attend them as they are in SL during a time I'm at work and unable to
attend (note text only like IRC I could attend)

And as Kelly stated, it is easier for them to discuss things with people who
are "right there".

But communication is very important, especially for those of us in the upper
balcony seats.  And I'm going to flame a little on Kelly here as he
mentioned "llGetObjectDetails"..... what exactly is it... and why isn't
there a wiki entry for it?

Let's do a little review of our communication channels.....

IRC...
The #OpenSL channel is almost always dead, very little conversation there at
all, and the number of lindens... well usually there is Rob. Vektor and Joe
make appearances in the #secondlife channel.  But they don't really talk

SL....
Office Hours...  1 - 3 times a week from select lindens.... all during
8am-5pm business hours and all of them excluding anyone at work without
access to SL

JIRA...
Seperate public and Internal developer JIRA's... and as stated... few
Lindens bother with the public one as it isn't as usefull to them...  This
is not good as it can and will lead to duplicate effort being spent on
issues... and missed issues.

WIKI...
I believe I already showed an example where this resource could, and should
have been used (llGetObjectDetails) but wasn't.   Seriously this should be
one of the primary sources of information on what is happening with SL is.
I moved the MapAPI information over to the WIKI.  And speaking of MapAPI...
an annoucement outside of the PJIRA about the new SLMapAPI should be done.
As it was I found it myself on accident 2 weeks before it was ever mentioned
on even the PJIRA

NEWSGROUP....
Honestly... how many of the Linden developers are signed up to this list?

And no the Lindens aren't the only ones at fault for not communicating, the
non-linden developers need to communicate about more then what new beef they
have with the Lindens.  Currently I believe Nicholaz is the only one
releasing an OpenSource build, although there was the "Sandbox Edition" for
1.18.0.6, Dale has his custom work he's working on...  But what I don't see
is discussion about how patches are working out..  I know Nicholaz has quite
a few people using his version... but unless we're one of the people using
it... we have no idea when a new release is... what new PJIRA patches he's
included, or even what issues he's had.

I'd like to see the release notes for the current "Nicholaz Edition" posted
here each time a release is made... because that right there is our test
bed... not "When is my patch going to get into the official client".... but
"When did it go into Nicholaz client.. and what are people saying"

You send a patch to the Lindens that's been real world tested... something
that has been live on the grid and in the hands of the users already.  They
are your QA... and believe me... they are the toughest QA department you
will ever see.

On 8/28/07, kelly at lindenlab.com <kelly at lindenlab.com> wrote:
>
> >
> > Second Life from the inside out:
> > http://nicholaz-beresford.blogspot.com/
> >
> >
> > Soft Linden wrote:
> >> Linden Lab isn't a monolithic "they."
> >
> > Well, I'd say that's an example of reality bubble.  From the inside
> > it may seem like this, from the outside it doesn't.  I hardly hear
> > anyone refer to a specific Linden, it's mostly "the Lindens" were
> > doing this or that.
> >
> >
> >> I normally appreciate your comments and criticism Nicholaz, because
> >> you've tended to be good about not complaining for complaining's sake,
> >> but pointing to specific things that need to be fixed. I don't see
> >> that here though, so maybe you could elaborate on that bubble, and
> >> suggest specific things individual Lindens might be able to do to
> >> improve the situation?
> >
> > What I mean by reality bubble is, and excuse if that sounds
> theroretical,
> > a social system of communication, information, values, goals that is
> > separated from the outside.
> >
> > A simple example is that as a Linden you have some idea when the next
> > update will be or happen and what will be part of it.  A non Linden
> > and even a developer who may be working on patches or tools based on
> > the source can expect it in a day or by the end of the next month.
> >
>
> Please excuse the rambling nature of the following.  I thought it was
> probably better to share my thoughts even if they are disjointed than to
> delete yet another half finished email.
>
> I agree that we are not as transparent as we should be.  I was thinking
> about it earlier today and I can't really think of a time when two lindens
> discussed a design issue on the public communication channels.  If I have
> a design issue I poke the developer(s) sitting next to me, poke some
> developers on our internal IRC or (as a generally last resort) email an
> internal mailing list (either for all internal developers or a specific
> studio).  The result to anyone not in linden is definitely a bubble with
> lindens poking their heads out to either announce things or interject in
> otherwise 'external' discussions.
>
> As soft has indicated we are constantly examining our various processes in
> the hopes of improving them.  I think we know that we aren't as
> transparent and connected to non-linden developers as we should be, but
> finding the correct process and policies is not always easy, and
> implementing them is usually even harder.  If by "reality bubble" you mean
> that we don't know what it looks like from the outside and aren't striving
> to make it better I think you are wrong.
>
> Some part of this is inherent in our partial-opensourceness: as everyone
> here knows significant pieces of the system are *not* open source such as
> the various server pieces.  I actually tend to work mostly on the back end
> in the simulator code or other back end services.  While I could discuss
> these externally it doesn't seem helpful.  I only mean that without the
> source it is hard to provide insight into the problems I am usually
> solving, which is my purpose when reaching out to other developers (that
> or to help them).  While we do want to open source the simulator code
> there is significant work that must happen first, and saying we want to
> certainly doesn't help any non-linden developers, so I'm not sure why we
> keep saying it.  It is a fact of life right now and we need to improve our
> process around it.
>
> Internally we have a single monolithic development project that includes
> the simulator, the viewers and the various libraries that are shared
> between them.  This means our exporting of the source is really
> *exporting* of the source and not sharing, it is more painful than it
> could potentially be and thus less frequent than it really should be.
>
> I have never worked on any other open source project.  I'm pretty sure I'm
> not the only linden developer who hasn't.  Insights from developers who
> have are incredibly useful, especially any with similar issues to us such
> a for-pay service or closed back end, both of which I believe to be very
> rare.  We do want to hear what is expected of us, what is wished of and
> what makes developing a pain.  It sometimes hurts, but we do want to hear
> it.
>
> Deployment schedules are a very interesting point.  I personally have to
> do significant digging to find out what is getting released or when;
> mostly because what I'm working on usually *isn't*, although it is an
> excellent point that for a non-linden developer it is much harder even
> when your changes *are* included.  I have pushed in the past for rigid
> time lines and policies on code freezes and deployments.  I still think
> they are the only way to ensure some sanity in as loose of a development
> environment as Linden has.  To be specific I think we should branch from
> trunk for a release at a preset regular interval, there should be some
> amount of preset testing time, some process for retesting and integration
> of bug fixes, and fixed release schedule.  This is not an argument I have
> won yet, but I think such policies would help all devs to know what was
> being released and when. :D  The fluidity and "when its ready" manner that
> things get completed, combined with the sheer volume of dev work always in
> progress tends to bump and push every conceivable time table around.
>
> That was a lot of work to say that while I have some idea when or what is
> getting released next I'm not sure it is as readily available information
> as otherwise believed even within linden.  What I do know: 1.18.3 is next
> and is viewer only, includes access to llGetObjectDetails which I wrote
> and actually went out to sims with the last rolling update and many many
> many bug fixes from 'fixed internally' as of a few weeks ago when it
> branched, and it will be in some form (that isn't 'required') really,
> really Soon Now(tm). (Hope I don't get busted for any of the previous, all
> of it subject to change without notice, no warranty on the information
> given, I reserve the right to be wrong and deny I ever said it. ;) ).
>
> And to conclude I think the following are things that should be available
> to open source developers but aren't: (hi rob! :) )
> * Daily code drops of our 'maintenance' branch, which is where OS
> contributions go first.  More frequent and regular releases of our
> 'release'(trunk) branch.
> * More communication between linden developers and non-linden developers,
> and more insight into linden's internal communication.  I'm not sure how
> to promote this really.
> * A better jira that remembers you were logged in via cookies, that lets
> you watch issues and receive emails on updates.  Until the public jira
> works as well as our internal jira it will not see the same usage from
> linden developers.
> * More communication on releases: what 'resolved internally' really means
> for a specific issue, when the next releases are, what is in the releases.
> Without significant change to our process this is probably just notice
> when maintenance gets merged to release(trunk) and when release is forked
> for testing to be released.
>
> Enough rambling for one night, I'll don my asbestos suit so feel free to
> let loose on me. :)
>
> - Kelly
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070828/4573941a/attachment-0001.htm