Change Description Template
From OpenLaszlo
Fill in as much of this as makes sense. Feel free to delete sections that do not apply.
Summary: Expand gimlets and control wingnuts
New Features: LPP-1234 Over-torqued wing nuts should be disallowed
Bugs Fixed: LPP-5678 Only right-handed gimlets are supported
Technical Reviewer: frodo@bag-end.com (verbal)
QA Reviewer: trinity@matrix.net (regression tests passed)
Doc Reviewer: arnold@t3.org (Message-Id: <20030708183546.B0B4F58245@icicle.pobox.com>)
Documentation:
Attempts to tighten wing nuts excessively will be automatically prevented by sending a
40kv pulse to the nut wings.
Release Notes:
Both left- and right-handed gimlets are supported for adjusting framus levels.
Overview:
Generalized framus code to handle both directions. Added upper-limit check to wingnut support.
Details:
framus.js: New optional parameter gimletDirection, defaults to 'right'. Level algorithm now
parameterized to work in either direction.
wingnut.java: Limit torque value, signal exception if above 11.
Tests:
Regression test on all platforms.
| Field | Description |
|---|---|
| Summary | Summary of the change. |
| New Features | One line descriptions of new features in this change, give Jira number if appropriate. |
| Bugs Fixed | Jira bug number and bug summary for each bug fixed in this change. |
| Reviewers | Each of the reviewer fields should contain an email address and some description of what the review consisted of. |
| Documentation | Prototype documentation for each new feature. |
| Release Notes | Prototype release notes for each bug fixed. |
| Overview | Manager-level description of code changes |
| Details | Reviewer-level description of intent of code changes. Most helpful if in source order, so your reviewer does not have to reverse-engineer your changes. Reviewer should ensure that code changes match this intent. |
| Tests | A description of how this change was tested. |
N.B.: Please list the features and bugs fixed in the format:
New Features: <the bug number> <the bug 1-liner>
or
Bugs Fixed: <the bug number> <the bug 1-liner>
1 per line, for each bug fixed in the check-in. This makes it much easier for the integrator and QA to grep for what bugs they should be documenting/closing/verifying. It is important to include both the bug number and the bug description: 1) in case there is a type-oh in the bug number, 2) because some members of the project to not have photographic memories and need help identifying the actual bug from a number.
