[sldev] Better support for the Open Source community

[Rob Lanphier]

Hi Matthew,

Your mail came at a time when we were already discussing these issues,
and actually spurred even more internal conversation at Linden Lab and
fixing of problems.

Comments below:

On 11/13/07 12:46 PM, Matthew Dowd wrote:
> I've not been able to compile the viewer since 1.18.3.
>
> 1.18.4 introduced a few new library dependencies not included in the library download - in particular c-ares. Whilst I've managed to hunt this component down, and at least get through the compilation stage - so far I've not managed to get a compiled version of c-ares which doesn't cause errors at the link stage (and my plea for help on this list didn't seem to get a response unless I missed an e-mail).
>   

Sorry, I had mentally checked that one off as "answered" because it was
in JIRA:
https://jira.secondlife.com/browse/VWR-2856

In general, JIRA is going to be a good place to discuss and hopefully
resolve this type of issue.  I think there was some confusion about when
the updated version was actually going to go out, because it went into
the pipeline at a point well before something useful to the community
went out.  However, I believe that this library is there in the 1.18.5.0
library bundle.

> 1.18.5 (which is in subversion) introduced another dependency - namely the Logitech LCD SDK. Again, it took some time to track this down, and again, although I finally got the source code for the LCD SDK and managed to get through the compilation, getting the right library compiled to get through the link step is again taking time to resolve.
>
> And this has been the case with previous releases too, when the source code hasn't included a dependency.
>   

Looking at the audit trail, I think this is fixed in the 1.18.5.0
library bundle as well.
> Now, I'm sure given time, patience and perserverance, I'll eventually work out all the require dependencies and get a build working - but this seems to me to be a complete and unncessary waste of time and effort. Presumedly, LL has some internal process for documenting new library dependencies in the source code, so that if a LL developer introduces a new dependency the rest of LL doesn't have the pain that the external opensource community seems to have to go through! Could this information not be shared with the external community, rather than expecting the community to muddle through and redocument this itself?
>   

Heh heh....you said "internal process" and "LL" in the same sentence. 
How cute.  ;-)

Actually, as it turns out we have multiple documents that describe
pieces of this process.  Writing this nearly sent me on the yak shaving
exercise of going off and merging documents before writing this. 
(Lindens:  see "Adding Third Party Libraries" and "Adding Files To
Projects" on our internal wiki).  Unfortunately, the documents don't
always get read, and even when it's followed to a tee, there still can
some delay between the point at which the dependency goes in, and the
point at which everything is added 100% correctly, especially if you're
pulling source from svn.secondlife.com.

I think there's a tension here that we need to resolve.  In order to
provide frequent source updates, those updates are going to have less
checking of library dependencies and such, because there's only so many
manual checks we have time to do.  Automated testing is of course the
ideal, and that's on our roadmap, but we don't have that yet.

One possibly underutilized resource here is the #opensl channel on
irc.efnet.org.  I think one of the big reasons why people had an easier
time getting things working in the early days (despite the hurdles) was
that they didn't toil in isolation.  The problems were spotted
practically in real-time.  IRC is the ideal channel for the sort of
one-liner "anyone know why my viewer build is failing on c-ares?" type
questions.  Ping me (llrobla) if you don't get a response and you stay
stumped.

> If LL wants to take the OS community seriously (or if LL wants to be taken seriously by the OS community), it really does need to do something about the issues in just getting the publically available source smoothly through a build step!
>   

We're working on it.  Over time, there's going to be further automation
(resulting in better reliability) as well as a gradual convergence of
internal and external processes.  In the meantime, please bear with us.

Rob



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071114/6e4a08dc/signature.pgp