Hi folks, There's a lot of moving parts for releasing the first viewer off of the http-texture branch (not the least of which being a name...stay tuned for that).
One thing we're pretty certain of: we want to have our first release by the end of this quarter (June 30), and preferably well in advance of that. So, it'll be important to get through the release cycle for this release as quickly as possible. However, we want to make sure you all are part of the process and have an opportunity to get what you (as a developer willing to shepherd a feature through the review process) think is important included, and that you know what you're signing up for. We want to move toward time-based releases, and keep the duration of each release cycle something best measured in weeks. It's probably premature to get into more detail than that without getting the first release under our belt, but if people have opinions about this subject, it can't hurt to share them. Here's the rough contour of what the release cycle will look like: * Phase I : Merge window - we'll provide the general guidelines for the release (e.g. stating what improvements we'd like to focus on). More on the merge window in a bit. * Phase II: Stabilization phase - bugfix phase. No new features, no big disruptive changes. Only fixes necessary to get the already completed features into shipable state * Phase III: RC cycle - very short cycle at the end of the stabilization phase. Only fixes for showstoppers, and only shallow bugfixes (no gutting/replacing subsystems...just the least disruptive change that fixes the problem, saving the "real" fix for the next cycle) For the merge window: Specific feature/patch proposals should be discussed on sldev@ (let at least one full business day pass without comment before considering silence assent). All checkins should have a corresponding JIRA task with the proposed patch, either attached in JIRA, or a pointer to a specific patchset in a public source repository somewhere (e.g. Bitbucket). The comments on the JIRA task should have a comment from another committer (not necessarily a Linden) who has thoroughly reviewed the patch, and is willing to stake their credibility as a committer that the patch should be safe for checkin. You'll need to take responsibility for the code you commit, especially if you commit a build breaker. Failure to do so may lead to you losing commit access, depending on the degree of carelessness exhibited. Reviewers will also be subject to scrutiny. More on what this means for this first release cycle in a separate mail. Rob _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
