[sldev] Viewer Source Release of RC-1.18.6.2

[Matthew Dowd]

Josh,

> we're *always* going to do another source drop soon, and the likelyhood 
> of any RC being followed by another one verges on 75%, so it just didn't 
> occur to me.

I fear you may have got the blunt edge of some growing frustrations within the open source developer community. Open Source is not just sticking the source code somewhere under an OS license, although that is a common mistake to make (I've been there). Successful Open Source projects adopt an Open Community development model (there isn't a single model fits all, and it takes time and effort to get right but the same development model is used by both internal and external developers).

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

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.

We are about a year in from LL's decision to opensource the client, but whilst to be fair some progress from from a "drop the source and run" model to a full open community development model has been made, there is still a long way to go and it has been at times painfully slow progress, and it isn't always clear how committed LL is to making such a move.

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

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.

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.

Matthew

_________________________________________________________________
Free games, great prizes - get gaming at Gamesbox. 
http://www.searchgamesbox.com