[sldev] Viewer Source Release of RC-1.18.6.2

[Joshua Bell]

Excellent discussion, BTW. Thanks for bringing this up.

Matthew Dowd wrote:
> In the case of SL, there really shouldn't be seperate internal and external source repositories - there should be a single one which can be read from outside (yes, there will be a need for private internally accessible only directories within that repository for the non-redist source code such as the bHear related code, and there will be a need for private internally accessible only branches, but modern source control systems like subversion support that level of granular access control).
>   
Trust me, we know. We've escalated the priority of moving to this model 
- which has been our intent all along - and hope to have significant, 
tangible progress here in Q108. The cmake experimenting that's been done 
internally is formalized into a project now that's basically the first 
step. As has been mentioned before here, our internal code base is a 
twisty maze of passages with both viewer and server code intertwingled. 
Teasing that apart is the next step, followed by moving to development 
of the viewer code in an external repository.
> A sourcecode drop should ideally be an integrated (and even automated) part of the process of making a public release (both stable and intermediate test releases), not, as currently appears, a manual and optional process which sometimes (I'm afraid) seems to be something of an afterthought.
>   
Agreed. We're in the process of getting hardware set up for an automated 
build farm that should be able to do source drops with each build, in 
the interim until the aforementioned projects are complete.
>> Since I *am* the person who manages the release schedule, here's the 
>> roadmap:
>>     
> I think what we would welcome from a roadmap is not only version numbers and rough (liable to change) dates, but also some idea of what is planned (again with the usual "this is provisional" caveats) for the new versions.
>   
Yes, this is something we should do a better job of. One issue is that 
our development model is basically "let projects into the trunk until we 
hit a freeze date, then freeze, then ship ASAP after the freeze", which 
means that until the freeze date what's in a release isn't known, and we 
try and turn things around pretty quickly (i.e. generate a viewer RC0 
within a few days)
> Also, we have within the jira, a lot of "fixed internally" issues, proposed features and bugs. In can take 2 or 3 releases (and sometimes months) before a such an internal fix actually makes it into a public release. It would be extremely useful to have some estimate in pjira against such "fixed internally" issues about which public version they are expected to make it into.
>   
Completely valid point. Right now we're strapped for bodies to correlate 
the various data sources. In the future we hope to use PJIRA exclusively 
for viewer-side work.
> There are also a long list of imported patches from the OS community which seem stuck in the pipeline - again it isn't clear from jira whether these are in progress, deliberately abandoned, stalled for some reason, requiring a refresh due to underlying changes in the base SL source code, or just forgotten/overlooked. Again some estimate in pjira which version such an imported patch would be expected to be in would be useful.
>   
Another completely valid point. Again, the long term fix is to reduce 
the barrier, not just get better at moving things across it. Otherwise, 
I don't have much useful to contribute, other than commenting that 
Lindens realize it's a huge problem and incredibly discouraging both 
internally and externally. Eliminating any notion of "us" vs. "them" is 
considered high priority... it's just been behind all the "ZOMG the grid 
is on fire!" items which are higher priority.