[sldev] Checkin process into http-texture branch
Rob Lanphier
robla at lindenlab.com
Fri Apr 17 14:43:49 PDT 2009
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
More information about the SLDev
mailing list