Last Updated 13 Dec 2022
* * * OBSOLETE NOTICE * * *
In July 2020 we disabled the old STR bug system from accepting new bugs, as this was
made obsolete by use of the new "GitHub Issues" system. Old bugs can still be managed
and closed with the old STR system using the below instructions, which were moved out
of the CMP to prevent accumulation of old info.
The following info is here just to help developers manage bugs still in the old system.
The techniques here will be phased out at some point in the future when we either fix
all old bugs (ha ha) or migrate them to GitHub Issues.
|
Software Trouble Reports ("STRs") are submitted
every time a user or vendor experiences a problem with or wants
a new feature in the FLTK software. STR reports are
maintained in a database with one of the following states:
- STR is closed with complete resolution
- STR is closed without resolution
- STR is active (waiting for feedback from submitter)
- STR is pending (additional information available)
- STR is new
Trouble reports are classified at one of the following
levels by the submitter:
- Request for enhancement
- Low, e.g. documentation error
- Moderate, e.g. unable to compile the software
- High, e.g. key functionality not working
- Critical, e.g. application crashes
Level 4 and 5 trouble reports are resolved in the next
software release. Level 1 to 3 trouble reports are scheduled for
resolution in a specific release at the discretion of the
release coordinator.
The scope of the problem is also identified as:
- Specific to a machine
- Specific to an operating system
- Applies to all machines and operating systems
New STRs are posted to the fltk.bugs forum for
priority 2 to 5 and the fltk.coredev forum for
priority 1 STRs. FLTK developers then discuss the STR and vote
to form consensus as to a proposed resolution.
If a general usage question is posted as a STR, any developer
may immediately close the STR without resolution using the
canned "support is not available" response which directs users
to the fltk.general forum.
During discussion, developers propose possible resolutions
for the STR and vote to approve them. Each developer posts one
vote of +1 (approve), -1 (veto), or 0 (abstain). At least three
developers must vote on the proposal, and the total of all votes
must be greater than 0. Once consensus is reached, the STR is
assigned to a developer that volunteers to resolve the STR.
The assigned developer summarizes the proposed changes in the
STR and makes the required changes, attaching a diff of the
changes to the STR as needed. The developer then notifies the
submitter that the change has been applied and closes the STR
when the resolution is confirmed by the submitter or after two
weeks, whichever comes first.
If the proposed changes do not resolve the problem, the
developer may unassign the STR to continue discussions on the
corresponding forum or privately discuss additional
modifications with the submitter in order to resolve the STR.
When closing the STR, the developer must set the fix version and
the first Git revision number which contains the
changes.
When a developer decides to fix a particular bug in the STR system,
the first step is to assign the STR to yourself, so that other developers
don't also try to work on it at the same time. If you decide you can no longer
work on the STR, unassign yourself from it and add a note accordingly.
To assign an STR to yourself, be sure the website has you logged in to your
developer account. Then, when viewing the STR, choose "Modify STR"
and modify these fields:
Status: New |
Change this to "Active"
|
Assigned To: Unassigned |
Change this to yourself if you'll be fixing this
|
Subsystem: Choose.. |
Change; 'Core library' and 'Documentation' are common
|
Also, check that the following fields are correct according to what's best
for this particular STR:
Published: |
Change to No if this is a private security issue
|
Priority: |
Change as needed. Unsolved priority 1-3 bugs will prevent a release.
|
Summary: |
Change only if OP's original summary is really misleading
|
Software Version: |
Take note of what the OP supplied
|
When attaching patches, use 'diff -Naur' or 'git diff',
the latter preferred, as it includes FLTK version numbers, useful if years
later someone tries to apply your patch. Try to include version#'s
in patch filenames (e.g. foo_v1.patch, foo_v2.patch..) so followup patches
are clear.
When you've applied a fix to Git, be sure to update the STR:
Status: |
Change to 'Closed w/resolution' if fixed and closing.
Otherwise, 'Active' until confirmed closed.
When closing an STR, non-devs can no longer update it or reply.
(Only devs can reply to closed STRs, and can re-open STRs)
|
Fix Version:
SVN rev#: (leave blank)
Fix Commit:
|
Set the version of FLTK your fix will be in, and add your Git commit#
(SHA1) here. Note: The SVN rev# is used only for old STR's.
|
Additional Text: |
Change this to "Fixed in Git repository" if you applied the fix.
Usually you only do this when closing.
|
Notes: |
Add any additional details/caveats about the fix you applied here.
Often the 'standard message' is enough for simple fixes.
|
|