Last week I wrote that the Beta Viewer and Development Viewer channels that carry release candidates are changing. Both have already pretty much stopped getting updates. The viewer development is going to parallel release channels like the server’s parallel release candidate channels.
Viewer development types watch the code repositories as they are often the first place we are likely to get a look at Linden Lab changes to the code. So, these people are interested in how things will change and where they can fine the code. For most of the rest of us, this is a non-issue. All we are interested in is where can we find a new version. For now there is nothing to point at.
When asked, Oz Linden provided some answers:
QUESTION: How will you know which repositories are active, and will they be reviewable?
Our intent is that sources for development projects will become publicly visible /approximately/ when both:
- A public test viewer is made available (whether as a Project or Beta viewer)
- The design, especially any server interactions, is believed to be reasonably stable. (If the goal of releasing a viewer is to find out whether or not a particular design works, we don’t want to put the sources out where someone might pull them because then important changes to the design may create compatibility problems; the materials project kept its sources private for some time for this reason).
I say approximately because each project will make that decision independently; for some, making sources public may be a high priority (such as getting important bug fixes out where others can pick them up), while others may take longer. This is a guideline for our teams, not a hard and fast promise, but we are very much aware that it’s in our interest to get new features adopted by the open source community in a timely way, so we have ample motivation to make sources public.
To that end, I will be maintaining a wiki page that will display all of our Viewer channels and the latest viewers in the channel. Channels that include candidate viewer cohorts (normally only the release channel) will display both the default viewer and the candidates. For each viewer, there will be a link to the repository, the changeset id it was built from, and an indicator as to whether or not that repository is public. I’ve already created the program to generate this page content, and will try to update the page promptly when changes are made. The page will appear shortly after we begin using the new viewer version management system (the generation program relies on queries against that service). Incidentally – this will be separate from the user-oriented official Alternate Viewers page, which will provide the download links for each publicly available viewer.
Bitbucket provides a ‘watch’ feature you can use to be notified when changes are made to repository – you can use that to monitor both viewer-release and any other repository, so I won’t be configuring email notices on any of the new repositories.
Which brings us to code reviews…
The Review Board instance at codereview.secondlife.com has been valuable, I think, but it has some significant problems – specifically it:
Isn’t integrated with Jira
- Isn’t integrated with Bitbucket
- Requires fairly complex manipulation to post reviews of code in repositories not directly descended from one of the configured repos (see Posting Failure in the wiki documentation) This goes directly to Nickys question, really, and I am not crazy about the idea of constantly having to configure each project repository… if only because it would get cluttered very quickly [and] is rather a pain for me to keep up to date (updates require that I re-merge changes we need that for some reason the developers have never integrated my contributions for)… we’re actually pretty far behind the most recent releases as a result.
Since I set up that review system, Bitbucket has significantly improved their display of differences in a commit and added some code review features (I like to think that my quite detailed feedback to them on this played some part in that). If you display the page for a specific commit, there is a way to comment on both the commit as a whole (a box at the top) and on any specific line (click on the speech bubble to the left of the line). The comments are then both mailed to the author of the commit and displayed on the page. There’s a way to reply to each, and there’s an Approve button at the top that registers your approval of the commit.
Using Bitbucket for reviews would place a premium on arranging your changes as a single commit that does not have any embedded merges. As a former/sometime git user, I prefer to do that anyway. It’s a little less convenient in Mercurial, but it’s not that hard.
On the whole, I think that using the Bitbucket review system would be much easier than the existing ReviewBoard; it seems to me that the only significant disadvantage is that it doesn’t post review requests to this list, but putting together an email with a link doesn’t seem to me to be too much to ask.
The request for opinions and experiments is directed to viewer developers.
I am guessing that in a week or two we will see code flowing through the new pipelines. There was pressure to get more changes through viewer development. Oz was saying there were code changes stacking up. That ‘stacking’ thing puts third party developers behind. So, I think that is adding pressure. More pressure = sooner.
Once we see how the new Beta and Project Viewers work I’ll have more to say about how to set them up and use them.