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

[kelly at lindenlab.com]

>
> 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